Bug 27522

Summary:

rendering of large vtk datasets very slow

Product:

DRI

Reporter:

Paulo César Pereira de Andrade <pcpa>

Component:

DRM/Radeon

Assignee:

Default DRI bug account <dri-devel>

Status:

RESOLVED MOVED

QA Contact:

Severity:

normal

Priority:

medium

Keywords:

NEEDINFO

Version:

XOrg git

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
% perf record invesalius; perf report 2>& 1 ....	none

Description Paulo César Pereira de Andrade 2010-04-07 13:00:17 UTC

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

Comment 1 Michel Dänzer 2010-04-08 01:06:17 UTC

(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.

Comment 2 Paulo César Pereira de Andrade 2010-04-09 12:29:09 UTC

(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.

Comment 3 Paulo César Pereira de Andrade 2010-04-09 13:57:25 UTC

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.

Comment 4 Martin Peres 2019-11-19 08:12:20 UTC

-- 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.