[Mesa-dev] [PATCH (9.1)] Revert "r600g: re-enable handling of DISCARD_RANGE, improving performance"
maraeo at gmail.com
Wed Feb 20 11:33:33 PST 2013
Well, I really wonder why it doesn't work with TF2. We have a lot of
piglit tests for DISCARD_RANGE (AKA INVALIDATE_RANGE in GL) and the
copy-buffer functionality and they all pass. There are actually 3
different implementations of copy-buffer: streamout, CP DMA, and async
DMA. It's highly unlikely that all 3 would be broken in the same way.
Other apps like openra also draw their GUI while using DISCARD_RANGE
to discard old data and there is no issue.
I need an apitrace to debug this. I wouldn't like to disable
DISCARD_RANGE just because of TF2, because everything else seems to be
working without any issues and because the performance regression can
turn out to be a show-stopper for some other apps.
On Sun, Feb 17, 2013 at 6:25 PM, Andreas Boll
<andreas.boll.dev at gmail.com> wrote:
> This reverts commit 1eedebc65b02130ef7a27062a1ed67972a317a08.
> Until we have a proper fix disable DISCARD_RANGE for now.
> It fixes the garbled ui in TF2.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58042
> Cc: Marek Olšák <maraeo at gmail.com>
> src/gallium/drivers/r600/r600_buffer.c | 2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/src/gallium/drivers/r600/r600_buffer.c b/src/gallium/drivers/r600/r600_buffer.c
> index 6df0d91..82630af 100644
> --- a/src/gallium/drivers/r600/r600_buffer.c
> +++ b/src/gallium/drivers/r600/r600_buffer.c
> @@ -137,6 +137,7 @@ static void *r600_buffer_transfer_map(struct pipe_context *ctx,
> r600_set_constants_dirty_if_bound(rctx, rbuffer);
> +#if 0 /* this is broken (see Bug 53130) */
> else if ((usage & PIPE_TRANSFER_DISCARD_RANGE) &&
> !(usage & PIPE_TRANSFER_UNSYNCHRONIZED) &&
> rctx->screen->has_streamout &&
> @@ -161,6 +162,7 @@ static void *r600_buffer_transfer_map(struct pipe_context *ctx,
> /* mmap and synchronize with rings */
> data = r600_buffer_mmap_sync_with_rings(rctx, rbuffer, usage);
More information about the mesa-dev