[RFC 0/7] UVD support for SI in amdgpu
Piotr Redlewski
predlewski at gmail.com
Thu Nov 9 10:53:16 UTC 2017
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));
Regards,
Piotr
>
> Regards,
> Christian.
>
> >
> > > > 2. I don't know why, but I couldn't get the uvd to boot without setting uvd mc
> > > > offsets before starting other engines. Because of that I set it in .sw_init
> > > > function. In my opinion this should be fixed as it generally doesn't follow
> > > > amdgpu driver architecture (hardware setup during software setup stage) and
> > > > probably will break suspending and resume (I didn't test it). As I mentioned,
> > > > I couldn't figure out why this is happening, so I count on help with finding fix
> > > > for this.
> > > > 3. I found some redefinitions in include/asic_reg/uvd/uvd_4_0_sh_mask.h. I guess
> > > > this file is generated, so fix should be made wherever it is generated from. For
> > > > now I removed offending lines just to silence the compiler warnings.
> > > > 4. I'm not sure whether I choose the right version for the uvd. Existing code in
> > > > si.c suggested that it should be 3.1, however I went with the 4.0, because for
> > > > this version there are available new style headers.
> > > I think the regs are pretty much the same between 3.x and 4.x so it
> > > should be fine.
> > Great.
> >
> > Regards,
> > Piotr
> > > Alex
> > >
> > >
> > > > Regards,
> > > > Piotr
> > > >
> > > > Piotr Redlewski (7):
> > > > drm/amdgpu: remove duplicated definitions of some of the SI registers
> > > > drm/amdgpu/uvd4: fix some register's mask and shift definitions
> > > > drm/amdgpu/gmc6: don't use vram location programmed by the vbios
> > > > drm/amdgpu/uvd4: add early init stage functions for uvd 4.0
> > > > drm/amdgpu/uvd4: add sw init and fini stages' functions for uvd 4.0
> > > > drm/amdgpu/uvd4: add hardware specific functions for uvd 4.0
> > > > drm/amdgpu: enable UVD for SI
> > > >
> > > > drivers/gpu/drm/amd/amdgpu/Makefile | 3 +-
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 6 +
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 14 +
> > > > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 114 ++-
> > > > drivers/gpu/drm/amd/amdgpu/dce_v6_0.h | 5 +
> > > > drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 7 -
> > > > drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 40 +-
> > > > drivers/gpu/drm/amd/amdgpu/si.c | 256 ++++++-
> > > > drivers/gpu/drm/amd/amdgpu/si_ih.c | 3 +
> > > > drivers/gpu/drm/amd/amdgpu/sid.h | 52 +-
> > > > drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c | 810 +++++++++++++++++++++
> > > > drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h | 29 +
> > > > .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h | 2 -
> > > > 13 files changed, 1273 insertions(+), 68 deletions(-)
> > > > create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
> > > > create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h
> > > >
> > > > --
> > > > 2.15.0
> > > >
> > > > _______________________________________________
> > > > amd-gfx mailing list
> > > > amd-gfx at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > > _______________________________________________
> > > amd-gfx mailing list
> > > amd-gfx at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
More information about the amd-gfx
mailing list