Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
Am 01.04.2014 15:47, schrieb Leo Liu:
From: Leo Liu leo@amd.com
This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
The patch itself is ok, but we should probably add an explanation why we
want to revert this.
Christian.
Signed-off-by: Leo Liu leo@amd.com
---
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;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
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.
---
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
Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Wed, Apr 2, 2014 at 3:09 PM, 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.
---
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
Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
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
Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
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
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
Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
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
Re: [Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
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
[Mesa-dev] [PATCH] Revert radeon: just don't map VRAM buffers at all
From: Leo Liu leo@amd.com
This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
Signed-off-by: Leo Liu leo@amd.com
---
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
