Bug 106053 - Drawing at screen boundary is very slow.
Summary: Drawing at screen boundary is very slow.
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-15 10:08 UTC by cosiekvfj
Modified: 2018-04-20 01:43 UTC (History)
10 users (show)

See Also:
i915 platform:
i915 features:


Attachments
bitmap for testing (53.02 KB, image/bmp)
2018-04-15 10:08 UTC, cosiekvfj
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cosiekvfj 2018-04-15 10:08:20 UTC
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?
Comment 1 Hi-Angel 2018-04-15 10:16:02 UTC
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
Comment 2 Marek Olšák 2018-04-15 15:40:51 UTC
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.
Comment 3 Roland Scheidegger 2018-04-16 21:55:47 UTC
(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).
Comment 4 Marek Olšák 2018-04-16 22:05:06 UTC
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.
Comment 5 Roland Scheidegger 2018-04-17 01:22:27 UTC
(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.