I packaged the software http://svn.softwarepublico.gov.br/trac/invesalius/wiki/ in mandriva (but there are ubuntu and fedora packages available in the above link), but it has a problem that appears to happen only with r300_dri.so. When running the software using fbdev to force swraster_dri.so, as forcing indirect rendering doesn't change anything, it runs slow, but doesn't lock the computer/mouse for almost 1 minute for every repaint. Using oprofile, and starting the application, loading a project and clicking the close button shows that most of the time is spent in kernel mode (70%ish, and I believe should be in the drm code, what would explain even the mouse pointer almost locked). My guess is that the issue is some condition where converting the data to triangles/textures becomes a lot slower then if just doing sw accel. I am sorry I don't have much other details, so this bug report is more of a heads up about possible issues with VTK. I contacted upstream of InVesalius, and they said they were looking at some possible options, and linked to http://www.cmake.org/Wiki/VTK_FAQ#How_to_handle_large_data_sets_in_VTK
(In reply to comment #1) > Using oprofile, and starting the application, loading a project and clicking > the close button shows that most of the time is spent in kernel mode (70%ish, > and I believe should be in the drm code, what would explain even the mouse > pointer almost locked). Please attach profile data. If you use sysprof 1.1.x (or a Git snapshot) with a recent kernel, you should get profiling information about the kernel as well.
(In reply to comment #1) > (In reply to comment #1) > > Using oprofile, and starting the application, loading a project and clicking > > the close button shows that most of the time is spent in kernel mode (70%ish, > > and I believe should be in the drm code, what would explain even the mouse > > pointer almost locked). > > Please attach profile data. If you use sysprof 1.1.x (or a Git snapshot) with a > recent kernel, you should get profiling information about the kernel as well. I just made an alternate test, that was to enable radeon kms, and now the performance is good, not as fast as when compared with a computer with an i965, but pretty usable.
Created attachment 34856 [details] % perf record invesalius; perf report 2>& 1 .... The file should give some good hint of what is wrong. It should be noted that it takes some time to load the user interface, and then tell it to load the proper project, so, the time percentage may not truly match what happened, because there was significant delay before starting rendering. Also, I did not wait until it finished rendering, i.e. when the mouse starts moving normally again, or it could give even worser idea of what may be wrong.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/122.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.