From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 40554] r200 falls back to software when clearing FBOs Date: Wed, 05 Dec 2012 15:20:41 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0403141580==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id ED070E6090 for ; Wed, 5 Dec 2012 07:20:40 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0403141580== Content-Type: multipart/alternative; boundary="1354720840.55eF1bBc1.29478"; charset="us-ascii" --1354720840.55eF1bBc1.29478 Date: Wed, 5 Dec 2012 15:20:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=40554 --- Comment #5 from Roland Scheidegger --- (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. --1354720840.55eF1bBc1.29478 Date: Wed, 5 Dec 2012 15:20:40 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 5 on bug 40554 from
(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.
--1354720840.55eF1bBc1.29478-- --===============0403141580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0403141580==--