[Bug 106053] Drawing at screen boundary is very slow.
https://bugs.freedesktop.org/show_bug.cgi?id=106053 --- Comment #5 from Roland Scheidegger --- (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.) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106053] Drawing at screen boundary is very slow.
https://bugs.freedesktop.org/show_bug.cgi?id=106053 --- Comment #4 from Marek Olšák --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106053] Drawing at screen boundary is very slow.
https://bugs.freedesktop.org/show_bug.cgi?id=106053 --- Comment #3 from Roland Scheidegger --- (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). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106053] Drawing at screen boundary is very slow.
https://bugs.freedesktop.org/show_bug.cgi?id=106053 Marek Olšák changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #2 from Marek Olšák --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106053] Drawing at screen boundary is very slow.
https://bugs.freedesktop.org/show_bug.cgi?id=106053 --- Comment #1 from Hi-Angel --- 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 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106053] Drawing at screen boundary is very slow.
https://bugs.freedesktop.org/show_bug.cgi?id=106053 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: cosiek...@o2.pl QA Contact: dri-devel@lists.freedesktop.org CC: alexdeuc...@gmail.com, emil.l.veli...@gmail.com, hi-an...@yandex.ru, lem...@gmail.com, madbiologist2...@outlook.com, mar...@gmail.com, mark.a.ja...@intel.com, mic...@daenzer.net, nhaeh...@gmail.com, nota...@gmail.com Created attachment 138844 --> https://bugs.freedesktop.org/attachment.cgi?id=138844&action=edit 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? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
