[Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at all"

Liu, Leo Leo.Liu at amd.com
Wed Apr 2 06:54:48 PDT 2014


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-bounces at 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 at 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 <alexdeucher at gmail.com>
>wrote:
>>> On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu <leo.liu at amd.com> wrote:
>>>> From: Leo Liu <leo.liu at 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 at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>_______________________________________________
>mesa-dev mailing list
>mesa-dev at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/mesa-dev




More information about the mesa-dev mailing list