No wait a second. As explained I've added the code in question specially
for VCE so if we disable it for VCE it won't be used.
I still think that reverting the patch is the right approach.
Christian.
Am 02.04.2014 15:54, schrieb Liu, Leo:
Okay. with "PIPE_TRANSFER_MAP_DIRECTLY", the regression can be fixed too.
Going to resend patch for this approach.
Leo
-----Original Message-----
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
Christian König
Sent: Wednesday, April 02, 2014 9:43 AM
To: Marek Olšák; Alex Deucher
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at
all"
I've applied the original patch because the same thing for reading textures
speeded up the decoding case with UVD quite significantly.
For VCE it reduced the CPU load as well, but I didn't checked if the encoding
time
stayed the same (which isn't the case). I think the problem is that VCE needs to
wait for the DMA or 3D engine to complete the upload before it can proceed and
because of this becomes idle, gets clocked down etc... When the frame has
finished uploading we clock VCE up and get it running again and this needs time.
Anyway I've added the patch specially for VCE, so just disabling it for VCE
doesn't
make much sense.
Christian.
Am 02.04.2014 15:34, schrieb Marek Olšák:
Also, the VCE code could use PIPE_TRANSFER_MAP_DIRECTLY to avoid the
blit and this patch wouldn't be needed.
Marek
On Wed, Apr 2, 2014 at 3:30 PM, Alex Deucher <alexdeuc...@gmail.com>
wrote:
On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu <leo....@amd.com> wrote:
From: Leo Liu <leo....@amd.com>
This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
In the case of VCE encoding with raw YUV file, CPU load directly to
VRAM is faster than combination of CPU writing to GTT and then blit
to VRAM with GPU.
Why was the original patch applied? I just want to make sure it
wasn't a bug fix for avoiding a sigbus or something similar if we ran
out of cpu visible vram.
Alex
---
src/gallium/drivers/radeon/r600_texture.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index 45a9508..3dfddca 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct
pipe_context *ctx,
if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
use_staging_texture = TRUE;
- /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
- if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
+ /* Untiled buffers in VRAM, which is slow for CPU reads */
+ if ((usage & PIPE_TRANSFER_READ) && !(usage &
+ PIPE_TRANSFER_MAP_DIRECTLY) &&
(rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
use_staging_texture = TRUE;
}
--
1.8.1.2
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
