[Bug 40554] New: r200 falls back to software when clearing FBOs

[Bug 40554] New: r200 falls back to software when clearing FBOs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40554

           Summary: r200 falls back to software when clearing FBOs
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/r200
        AssignedTo: dri-devel@lists.freedesktop.org
        ReportedBy: stefandoesinger@gmx.at


Created an attachment (id=50814)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=50814)
Sample application

glClear(GL_COLOR_BUFFER_BIT) causes a software fallback when a FBO is bound.
The line in the debug output that signals this fallback is

r200Clear: swrast clear, mask: 100

0x100 is BUFFER_BIT_COLOR0 as far as I can see, which is indeed not handled in
that function. I have attached a sample application that is a side product of
attempting to reproduce bug 40552. The sample doesn't crash(yet), but it
reproduces the software fallback.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 40554] r200 falls back to software when clearing FBOs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40554

--- Comment #1 from Roland Scheidegger <sroland@vmware.com> 2011-09-02 17:21:26 PDT ---
Hmm I guess at least when using the kernel_mm path (which is just
_mesa_meta_Clear) there shouldn't be any swrast fallback. Not quite sure though
how well fbos will actually work...
The old kernel clear path is quite a mess anyway (though it has to be said
fastzclear was fast...).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 40554] r200 falls back to software when clearing FBOs

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 717 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=40554

Stefan Dösinger <stefandoesinger@gmx.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Stefan Dösinger <stefandoesinger@gmx.at> ---
This bug appears to have been fixed. I no longer get any software fallback
debug output in my sample application, and the performance of Wine with FBOs is
too high to suspect that there are any SW fallbacks.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2224 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40554] r200 falls back to software when clearing FBOs

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 279 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=40554

--- Comment #3 from Roland Scheidegger <sroland@vmware.com> ---
FWIW the relevant commit fixing this bug was
de694b6b10b7ce23a00cd7296a955f162704ee62.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1095 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40554] r200 falls back to software when clearing FBOs

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 421 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=40554

--- Comment #4 from Stefan Dösinger <stefandoesinger@gmx.at> ---
Clearing by drawing geometry? Isn't that somewhat inefficient? Doesn't the
hardware have a nicer way to deal with this?

It's now also applying ATI_fragment_shader shaders when clearing. I'll send a
patch for that.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1259 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40554] r200 falls back to software when clearing FBOs

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1328 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=40554

--- Comment #5 from Roland Scheidegger <sroland@vmware.com> ---
(In reply to comment #4)
> Clearing by drawing geometry? Isn't that somewhat inefficient? Doesn't the
> hardware have a nicer way to deal with this?
There are two normal methods how you can do ordinary buffer clears on this hw.
1) With the 2d blitter.
2) With the 3d engine (by drawing a tri/quad).
In practice, both should most likely have the same performance, as it should be
limited by memory bandwidth. I believe in theory the 2d blitter might be faster
for this class of hardware, but IIRC you also get problems with 3d engine
caches etc. Also, if you use 2d blit, you need to clear color and depth buffer
separately.
For depth/stencil buffer, you could use fast z clears (in some cases - it is
tricky, for instance can't clear depth and stencil individually and not with
pixel granularity viewport), which just sets a bit per tile saying this block
is cleared. All hyperz functionality (which fast z clear is) is however defunct
since dri2 (dri1 had it working mostly, was never enabled by default).

> 
> It's now also applying ATI_fragment_shader shaders when clearing. I'll send
> a patch for that.
Hmm yes that sounds wrong.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel