Created attachment 138844 [details] bitmap for testing When a partially visible sprites are drawn to the screen, fps drops really badly. code tested: https://gist.github.com/vfjpl/bd442e34036547e4ccb05200762fa274 fully visible = 73.8 fps fully invisible = 394 fps partially visible = 5.75 fps The same situation is happening on Allegro library. I don't know enough OpenGL to test it directly. I can provide more test results. Just ask me to do it. Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org R300 Project (0x1002) Device: ATI RC410 (0x5a62) Version: 17.3.7 Accelerated: yes Video memory: 128MB Unified memory: no Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 And small question. Why Max core profile shows 0.0? Should I open another bug-report?
Can't comment on the rest, but > And small question. Why Max core profile shows 0.0? Should I open another bug-report? This is because the OpenGL version r300g supports didn't have the separation to core/compat profile. See also this comment https://bugs.freedesktop.org/show_bug.cgi?id=103506#c8
r300-r500 hardware capabilities don't meet the requirements of OpenGL core profile. r300g on RC410 uses software emulation for vertex shaders and clipping (the same code as llvmpipe), because the hardware doesn't have any vertex processor and clipper.
(In reply to Marek Olšák from comment #2) > r300g on RC410 uses software emulation for vertex shaders and clipping (the > same code as llvmpipe), because the hardware doesn't have any vertex > processor and clipper. Can't the chip do guardband clipping? I thought all radeon chips (starting from r100) could do this, regardless if they support hw tnl. I could be wrong though (and I wouldn't know how large the guardband would be, and certainly draw's handling of guardband if you enable it is a bit lacking, since hw has fixed limits whereas draw will use a guardband twice the size of the viewport).
I think the hw doesn't have a clipper, though it shouldn't be hard to verify if it's true. Yeah, draw could use some optimizations for the clipper, e.g. the guardband, but simply doing culling (not clipping) should be enough for point sprites.
(In reply to Marek Olšák from comment #4) > I think the hw doesn't have a clipper, though it shouldn't be hard to verify > if it's true. Yeah, draw could use some optimizations for the clipper, e.g. > the guardband, but simply doing culling (not clipping) should be enough for > point sprites. That's what I meant with guardband clipping: there's no actual clipping, but the hw will still cull pixels outside the viewport. Hence it probably would be better if draw wouldn't clip if a primitive doesn't fit into the viewport, but fits into the (hw) guardband. (And you are right that point sprites are a bit of a special case.)
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.