| Bug ID | 106053 |
|---|---|
| Summary | Drawing at screen boundary is very slow. |
| Product | Mesa |
| Version | unspecified |
| Hardware | All |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/r300 |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | cosiekvfj@o2.pl |
| QA Contact | dri-devel@lists.freedesktop.org |
| CC | alexdeucher@gmail.com, emil.l.velikov@gmail.com, Hi-A= ngel@yandex.ru, lemody@gmail.com, madbiologist2016@outlook.com,= maraeo@gmail.com, mark.a.janes@intel.com, michel@daenzer.net, = nhaehnle@gmail.com, notasas@gmail.com |
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 =3D 73.8 fps fully invisible =3D 394 fps partially visible =3D 5.75 fps The same situation is happening on Allegro library. I don't know enough Ope= nGL 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 separatio= n to core/compat profile. See also this comment https://bugs.freedesktop.org/show_b= ug.cgi?id=3D103506#c8
| What | Removed | Added |
|---|---|---|
| Resolution | --- | NOTABUG |
| Status | NEW | RESOLVED |
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 proces= sor and clipper.
(In reply to Marek Ol=C5=A1=C3=A1k from comment #2) > r300g on RC410 uses software emulation for verte= x 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 lackin= g, 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 poi= nt sprites.
(In reply to Marek Ol=C5=A1=C3=A1k 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 enoug= h 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 b= it of a special case.)