Summary: | Very slow performance when rendering scenes with transparency, probably caused by excessive copying (intel_miptree_map()) | ||
---|---|---|---|
Product: | Mesa | Reporter: | Steve Holland <sdh4> |
Component: | Drivers/DRI/i965 | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Status: | RESOLVED MOVED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | ||
Version: | 17.1 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Steve Holland
2017-06-26 03:25:51 UTC
1. What application is this? 2. "has slowed by 10-100x" compared to what? Some earlier version of Mesa? Application is dgscope, a newer, not yet published version of http://thermal.cnde.iastate.edu/dataguzzler/download/dgscope-export-2.0.0-beta21.tar.gz This cropped up when we discovered we had failed to set GLUT_ALPHA in glutInitDisplayMode() (oops!). Other drivers had drawn transparency just fine without GLUT_ALPHA, but this one was drawing everything as fully opaque. The 10-100x slowdown is compared to previous version of dgscope (without GLUT_ALPHA) running on 3-year old hardware under Fedora 25. Will get you more clarity shortly. Curiously, the slowdown doesn't seem to occur if the entire scene has 100% opacity. Comparison system running exactly the same application, but running Fedora 25 mesa-dri-drivers-13.0.4-3.fc25 and older Intel graphics "Haswell-ULT Integrated Graphics Controller (rev 0b)" is a bit sluggish (say ~3 fps) at a particular rendering operation (transparent text over transparent image). Newer system (Mesa 17.1.3, Kaby Lake HD Graphics 620, Fedora 26 beta) on the same operation is 0.3 fps. Same operations with software rendering forced (by LIBGL_ALWAYS_SOFTWARE=1) are 10+fps on both platforms Just rendering the image is fast in all cases, transparent or not. Overlaying the text character-by-character with glutBitmapCharacter() seems to be what is slowing things down. (In reply to Steve Holland from comment #3) > Comparison system running exactly the same application, but running Fedora 25 > mesa-dri-drivers-13.0.4-3.fc25 and older Intel graphics "Haswell-ULT > Integrated Graphics Controller (rev 0b)" is a bit sluggish (say ~3 fps) at a > particular rendering operation (transparent text over transparent image). > Newer system (Mesa 17.1.3, Kaby Lake HD Graphics 620, Fedora 26 beta) on the > same operation is 0.3 fps. > > Same operations with software rendering forced (by LIBGL_ALWAYS_SOFTWARE=1) > are 10+fps on both platforms > > Just rendering the image is fast in all cases, transparent or not. > Overlaying the text character-by-character with glutBitmapCharacter() seems > to be what is slowing things down. My recommendation is to implement text rendering using other methods. It is quite unlikely that there is interest to optimize legacy glBitmap path. From the trace it also seems like the implementation of glutBitmapCharacter() is very unoptimal and might not even cache the font and you need to call it for each character. You could speed this phase up significantly for example by using traditional method of rendering textured quads (that use texture atlas which contains the font glyphs). This pushes the abstraction down a bit but will definitely be worth it. It seems like for every character rendered the driver is copying the entire window image back and forth, mipmapping and unmapping the entire window. Not at all sure why it is necessary. But I understand the API is rather obsolete. Really the the sensible destination for improvement effort would be freeglut, no? I think GLUT is still a very widely used API. (In reply to Steve Holland from comment #5) > It seems like for every character rendered the driver is copying the entire > window image back and forth, mipmapping and unmapping the entire window. Not > at all sure why it is necessary. But I understand the API is rather > obsolete. FWIW I don't think the whole content is copied but as glBitmap() gets called per character basis (which the API forces) it causes a lot of map/unmap of the buffer per each frame where we need to copy those bitmaps in. > Really the the sensible destination for improvement effort would be > freeglut, no? I think GLUT is still a very widely used API. GLUT could be still used but IMO text rendering should be implemented by the app itself and not rely on glutBitmapCharacter(). There are many tutorials/examples (and actually even ready helper libraries) in the web how to get started. -- 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/mesa/mesa/issues/1606. |
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.