[RFC 0/7] UVD support for SI in amdgpu

[Christian König]

Am 09.11.2017 um 11:53 schrieb Piotr Redlewski:
> On Thu, Nov 09, 2017 at 11:09:42AM +0100, Christian König wrote:
>> Am 09.11.2017 um 10:54 schrieb Piotr Redlewski:
>>> On Wed, Nov 08, 2017 at 06:54:18PM -0500, Alex Deucher wrote:
>>>> On Wed, Nov 8, 2017 at 5:38 PM, Piotr Redlewski <predlewski at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Following series implements UVD support for SI in amdgpu driver. Code is based
>>>>> on CIK's UVD support in amdgpu and SI's UVD support in radeon drivers. To work,
>>>>> it requires tahiti uvd firmware with added header - I've created simple script
>>>>> to produce exactly this, so if anyone is interested it can be found here:
>>>>> https://gist.github.com/anonymous/6d974a970340f7f64b6fcc4f95267e43
>>>>>
>>>>> Code is based on amd-staging-drm-next branch in Alex's tree. After applying
>>>>> these patches, uvd boots up and seems to work ok. I've tested it with vdpauinfo
>>>>> and mpv.
>>>>>
>>>>> Some comments/issues for the patches:
>>>>> 1. To make uvd work, I had to bring back fb location programming. Using location
>>>>> programmed by vbios, vram location is not available for uvd mc (at least on my
>>>>> machine) due to too wide address. Starting address is 40-bit long for fb, but
>>>>> uvd mc supports only 32-bits (judging by comments in amdgpu code and actual code
>>>>> in radeon driver)
>>>> Something else must be going on.  The vram location is irrelevant with
>>>> respect to the limitations of UVD.  I think the limitations with UVD
>>>> are more to do with the location of the active buffers relative to
>>>> each other rather than the absolute location of some aperture in the
>>>> GPU's address space.  CI has the same limitation as I recall so there
>>>> is probably a bug somewhere.  Windows has used the fb location as set
>>>> by the vbios since evergreen, so it definitely should work.
>>>>
>>> If this is the case, then there must be something missing in UVD mc controller
>>> programming. When using vbios, I get following location:
>>> amdgpu 0000:01:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
>>>
>>> When UVD bo is created, it starts at address 0xf400243000 and this value is used
>>> for programming UVD mc offsets. Programming is done in the following way:
>>> addr = (adev->uvd.gpu_addr + AMDGPU_UVD_FIRMWARE_OFFSET) >> 3;
>>> WREG32(mmUVD_VCPU_CACHE_OFFSET0, addr);
>>>
>>> Because address of the bo is wider than 32-bit, this won't work. It would be the
>>> same if UVD bo would be created at the beginning of the VRAM.
>>>
>>> Any ideas how to handle this?
>> Are you programming UVD_LMI_EXT40_ADDR?
>>
>> But I'm not sure if we ever handled that correctly in the SI code.
> Yes, I do it exactly the same as it is done in radeon (and CIK in amdgpu):
>   /* bits 32-39 */
> addr = (adev->uvd.gpu_addr >> 32) & 0xFF;
> WREG32(mmUVD_LMI_EXT40_ADDR, addr | (0x9 << 16) | (0x1 << 31));

Ok, I've checked the firmware in the meantime and found that we never 
released firmware which supports the full 40bit addressing.

That's why this will never work correctly. Going to check if we can get 
updated firmware out of the door.

Regards,
Christian.

>
> Regards,
> Piotr