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

[Christian König]

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-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
>