On Thu, Nov 09, 2017 at 01:17:36PM +0100, Christian König wrote: > 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 > > > > > <predlew...@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.
Ok, so let's wait for the new firmware. Thanks for your help Christian. Regards, Piotr > > Regards, > Christian. > > > > > Regards, > > Piotr > > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
