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 <[email protected]> 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
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
