I'm pleased to announce the initial release of the new amdgpu driver. This is a partial replacement for the radeon driver for newer AMD asics. A number of components are still shared. Here is a comparison of the radeon and amdgpu stacks:
1. radeon stack kernel driver: radeon.ko libdrm: libdrm_radeon mesa: radeon, r200, r300, r600, radeonsi ddx: xf86-video-ati
2. amdgpu stack kernel driver: amdgpu.ko libdrm: libdrm_amdgpu mesa: radeonsi ddx: xf86-video-amdgpu
Older asics will continue to be supported by the radeon stack; new asics will be supported by the amdgpu stack. CI (Sea Islands) asics have support in both driver stacks, but this is purely for testing purposes. CI parts are officially supported in the radeon stack. Support for CI on the amdgpu stack is determined by a config option in the kernel. CI support is not enabled by default for amdgpu.
Most of our focus has been on Carrizo support, so there are some gaps in the dGPU support for Tonga and Iceland, notably power management. Those gaps will be filled in eventually.
Also included in this code base are full register headers for just about every block on the asics.
Barring the gaps mentioned above, the driver stack is functionally on par with radeon including: - OpenGL 3.3 support using the radeonsi mesa driver - Video decode support using UVD - Video encode support using VCE
The code can be found in the amdgpu branches of the following git trees. xf86-video-amdgpu: http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu mesa: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
To test the new driver stack you will need to specify a device section in your xorg.conf with the driver set to amdgpu rather than radeon.
Please review!
Thanks,
The AMD Linux Driver Team
On Mon, Apr 20, 2015 at 6:33 PM, Alex Deucher alexdeucher@gmail.com wrote:
I'm pleased to announce the initial release of the new amdgpu driver. This is a partial replacement for the radeon driver for newer AMD asics. A number of components are still shared. Here is a comparison of the radeon and amdgpu stacks:
- radeon stack
kernel driver: radeon.ko libdrm: libdrm_radeon mesa: radeon, r200, r300, r600, radeonsi ddx: xf86-video-ati
- amdgpu stack
kernel driver: amdgpu.ko libdrm: libdrm_amdgpu mesa: radeonsi ddx: xf86-video-amdgpu
Older asics will continue to be supported by the radeon stack; new asics will be supported by the amdgpu stack. CI (Sea Islands) asics have support in both driver stacks, but this is purely for testing purposes. CI parts are officially supported in the radeon stack. Support for CI on the amdgpu stack is determined by a config option in the kernel. CI support is not enabled by default for amdgpu.
Most of our focus has been on Carrizo support, so there are some gaps in the dGPU support for Tonga and Iceland, notably power management. Those gaps will be filled in eventually.
Also included in this code base are full register headers for just about every block on the asics.
Barring the gaps mentioned above, the driver stack is functionally on par with radeon including:
- OpenGL 3.3 support using the radeonsi mesa driver
- Video decode support using UVD
- Video encode support using VCE
The code can be found in the amdgpu branches of the following git trees. xf86-video-amdgpu: http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu mesa: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
I forgot to mention, the latest ucode can be found here: http://people.freedesktop.org/~agd5f/radeon_ucode/
Alex
To test the new driver stack you will need to specify a device section in your xorg.conf with the driver set to amdgpu rather than radeon.
Please review!
Thanks,
The AMD Linux Driver Team
Hi Alex,
On 20 April 2015 at 23:33, Alex Deucher alexdeucher@gmail.com wrote:
I'm pleased to announce the initial release of the new amdgpu driver. This is a partial replacement for the radeon driver for newer AMD asics. A number of components are still shared. Here is a comparison of the radeon and amdgpu stacks:
- radeon stack
kernel driver: radeon.ko libdrm: libdrm_radeon mesa: radeon, r200, r300, r600, radeonsi ddx: xf86-video-ati
- amdgpu stack
kernel driver: amdgpu.ko libdrm: libdrm_amdgpu mesa: radeonsi ddx: xf86-video-amdgpu
Older asics will continue to be supported by the radeon stack; new asics will be supported by the amdgpu stack. CI (Sea Islands) asics have support in both driver stacks, but this is purely for testing purposes. CI parts are officially supported in the radeon stack. Support for CI on the amdgpu stack is determined by a config option in the kernel. CI support is not enabled by default for amdgpu.
Most of our focus has been on Carrizo support, so there are some gaps in the dGPU support for Tonga and Iceland, notably power management. Those gaps will be filled in eventually.
Also included in this code base are full register headers for just about every block on the asics.
Barring the gaps mentioned above, the driver stack is functionally on par with radeon including:
- OpenGL 3.3 support using the radeonsi mesa driver
- Video decode support using UVD
- Video encode support using VCE
The code can be found in the amdgpu branches of the following git trees. xf86-video-amdgpu: http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu mesa: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
To test the new driver stack you will need to specify a device section in your xorg.conf with the driver set to amdgpu rather than radeon.
Please review!
Do you plan to sending out the libdrm patches to the ML ? I have a few comments that you might be interested in :-)
Cheers, Emil
On Tue, Apr 21, 2015 at 11:56 AM, Emil Velikov emil.l.velikov@gmail.com wrote:
Hi Alex,
On 20 April 2015 at 23:33, Alex Deucher alexdeucher@gmail.com wrote:
I'm pleased to announce the initial release of the new amdgpu driver. This is a partial replacement for the radeon driver for newer AMD asics. A number of components are still shared. Here is a comparison of the radeon and amdgpu stacks:
- radeon stack
kernel driver: radeon.ko libdrm: libdrm_radeon mesa: radeon, r200, r300, r600, radeonsi ddx: xf86-video-ati
- amdgpu stack
kernel driver: amdgpu.ko libdrm: libdrm_amdgpu mesa: radeonsi ddx: xf86-video-amdgpu
Older asics will continue to be supported by the radeon stack; new asics will be supported by the amdgpu stack. CI (Sea Islands) asics have support in both driver stacks, but this is purely for testing purposes. CI parts are officially supported in the radeon stack. Support for CI on the amdgpu stack is determined by a config option in the kernel. CI support is not enabled by default for amdgpu.
Most of our focus has been on Carrizo support, so there are some gaps in the dGPU support for Tonga and Iceland, notably power management. Those gaps will be filled in eventually.
Also included in this code base are full register headers for just about every block on the asics.
Barring the gaps mentioned above, the driver stack is functionally on par with radeon including:
- OpenGL 3.3 support using the radeonsi mesa driver
- Video decode support using UVD
- Video encode support using VCE
The code can be found in the amdgpu branches of the following git trees. xf86-video-amdgpu: http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu mesa: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
To test the new driver stack you will need to specify a device section in your xorg.conf with the driver set to amdgpu rather than radeon.
Please review!
Do you plan to sending out the libdrm patches to the ML ? I have a few comments that you might be interested in :-)
Yeah, just sent them out now. Ran out of time last night. Some of the patches in the kernel and the ddx patch are really big so probably too big for the ML.
Alex
Cheers, Emil
On 21/04/15 16:41, Alex Deucher wrote:
On Tue, Apr 21, 2015 at 11:56 AM, Emil Velikov emil.l.velikov@gmail.com wrote:
Hi Alex,
On 20 April 2015 at 23:33, Alex Deucher alexdeucher@gmail.com wrote:
I'm pleased to announce the initial release of the new amdgpu driver. This is a partial replacement for the radeon driver for newer AMD asics. A number of components are still shared. Here is a comparison of the radeon and amdgpu stacks:
- radeon stack
kernel driver: radeon.ko libdrm: libdrm_radeon mesa: radeon, r200, r300, r600, radeonsi ddx: xf86-video-ati
- amdgpu stack
kernel driver: amdgpu.ko libdrm: libdrm_amdgpu mesa: radeonsi ddx: xf86-video-amdgpu
Older asics will continue to be supported by the radeon stack; new asics will be supported by the amdgpu stack. CI (Sea Islands) asics have support in both driver stacks, but this is purely for testing purposes. CI parts are officially supported in the radeon stack. Support for CI on the amdgpu stack is determined by a config option in the kernel. CI support is not enabled by default for amdgpu.
Most of our focus has been on Carrizo support, so there are some gaps in the dGPU support for Tonga and Iceland, notably power management. Those gaps will be filled in eventually.
Also included in this code base are full register headers for just about every block on the asics.
Barring the gaps mentioned above, the driver stack is functionally on par with radeon including:
- OpenGL 3.3 support using the radeonsi mesa driver
- Video decode support using UVD
- Video encode support using VCE
The code can be found in the amdgpu branches of the following git trees. xf86-video-amdgpu: http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu mesa: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
To test the new driver stack you will need to specify a device section in your xorg.conf with the driver set to amdgpu rather than radeon.
Please review!
Do you plan to sending out the libdrm patches to the ML ? I have a few comments that you might be interested in :-)
Yeah, just sent them out now. Ran out of time last night. Some of the patches in the kernel and the ddx patch are really big so probably too big for the ML.
Fair enough, did not mean to come out as impatient - was the first thing that pope at my email client after a short break.
Just a random question on the ddx front - do you see many benefits of supporting old xservers ? If you target xserver 1.16 and later you can drop a fair bit of code/wrappers - Non DRI2 enabled xserver. - HAS_DEVPRIVATEKEYREC (new with 1.10, released 4+ years ago) - xorg-list (new with 1.12, released 3+ years ago) - DRI2_PRIME (new with 1.13, released 2+ years ago) - AMDGPU_PIXMAP_SHARING (XF86_CRTC_VERSION >= 5, new with 1.13) - Support for external the glamor library (new with 1.16)
While you're there you might want to drop support for xextproto pre 7.1. 7.1.0 was released 6+ years ago.
The README and .gitignore mention xf86-video-ati.
Hope you find any of the above useful :)
-Emil
Hi Alex,
For the core driver patch:
+config DRM_AMDGPU + tristate "AMD GPU" + depends on DRM && PCI + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + select FW_LOADER + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select DRM_TTM + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select DRM_AMD_GNB_BUS + select INTERVAL_TREE
I think DRM_AMD_GNB_BUS is not used, we can probably remove it now.
+/* TODO: Here are things that needs to be done : + * - surface allocator & initializer : (bit like scratch reg) should + * initialize HDP_ stuff on RS600, R600, R700 hw, well anythings + * related to surface + * - WB : write back stuff (do it bit like scratch reg things) + * - Vblank : look at Jesse's rework and what we should do + * - r600/r700: gart & cp + * - cs : clean cs ioctl use bitmap & things like that. + * - power management stuff + * - Barrier in gart code + * - Unmappabled vram ? + * - TESTING, TESTING, TESTING + */ + +/* Initialization path: + * We expect that acceleration initialization might fail for various + * reasons even thought we work hard to make it works on most + * configurations. In order to still have a working userspace in such + * situation the init path must succeed up to the memory controller + * initialization point. Failure before this point are considered as + * fatal error. Here is the init callchain : + * amdgpu_device_init perform common structure, mutex initialization + * asic_init setup the GPU memory layout and perform all + * one time initialization (failure in this + * function are considered fatal) + * asic_startup setup the GPU acceleration, in order to + * follow guideline the first thing this + * function should do is setting the GPU + * memory controller (only MC setup failure + * are considered as fatal) + */ + These should be outdated, and I think they can be removed now.
For the uapi header patch:
+#define AMDGPU_TILING_MACRO 0x1 +#define AMDGPU_TILING_MICRO 0x2 +#define AMDGPU_TILING_SWAP_16BIT 0x4 +#define AMDGPU_TILING_R600_NO_SCANOUT AMDGPU_TILING_SWAP_16BIT +#define AMDGPU_TILING_SWAP_32BIT 0x8 +/* this object requires a surface when mapped - i.e. front buffer */ +#define AMDGPU_TILING_SURFACE 0x10 +#define AMDGPU_TILING_MICRO_SQUARE 0x20 +#define AMDGPU_TILING_EG_BANKW_SHIFT 8 +#define AMDGPU_TILING_EG_BANKW_MASK 0xf +#define AMDGPU_TILING_EG_BANKH_SHIFT 12 +#define AMDGPU_TILING_EG_BANKH_MASK 0xf +#define AMDGPU_TILING_EG_MACRO_TILE_ASPECT_SHIFT 16 +#define AMDGPU_TILING_EG_MACRO_TILE_ASPECT_MASK 0xf +#define AMDGPU_TILING_EG_TILE_SPLIT_SHIFT 24 +#define AMDGPU_TILING_EG_TILE_SPLIT_MASK 0xf +#define AMDGPU_TILING_EG_STENCIL_TILE_SPLIT_SHIFT 28 +#define AMDGPU_TILING_EG_STENCIL_TILE_SPLIT_MASK 0xf ...... +#define SI_TILE_MODE_COLOR_LINEAR_ALIGNED 8 +#define SI_TILE_MODE_COLOR_1D 13 +#define SI_TILE_MODE_COLOR_1D_SCANOUT 9 +#define SI_TILE_MODE_COLOR_2D_8BPP 14 +#define SI_TILE_MODE_COLOR_2D_16BPP 15 +#define SI_TILE_MODE_COLOR_2D_32BPP 16 +#define SI_TILE_MODE_COLOR_2D_64BPP 17 +#define SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP 11 +#define SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP 12 +#define SI_TILE_MODE_DEPTH_STENCIL_1D 4 +#define SI_TILE_MODE_DEPTH_STENCIL_2D 0 +#define SI_TILE_MODE_DEPTH_STENCIL_2D_2AA 3 +#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3 +#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2 + +#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
It looks these definitions are not used by libdrm_amdgpu anymore (and even by the kernel driver). Maybe we can remove the unused definitions, and move the used ones to amdgpu.h instead. Besides, I think we'd better remove 'R600/EG/SI/CIK' from the naming.
Other than the comments above, the kernel series are Acked-by: Jammy Zhou Jammy.Zhou@amd.com
Regards, Jammy
-----Original Message----- From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Alex Deucher Sent: Tuesday, April 21, 2015 6:34 AM To: Maling list - DRI developers; mesa-dev@lists.freedesktop.org Cc: Deucher, Alexander Subject: Initial amdgpu driver release
I'm pleased to announce the initial release of the new amdgpu driver. This is a partial replacement for the radeon driver for newer AMD asics. A number of components are still shared. Here is a comparison of the radeon and amdgpu stacks:
1. radeon stack kernel driver: radeon.ko libdrm: libdrm_radeon mesa: radeon, r200, r300, r600, radeonsi ddx: xf86-video-ati
2. amdgpu stack kernel driver: amdgpu.ko libdrm: libdrm_amdgpu mesa: radeonsi ddx: xf86-video-amdgpu
Older asics will continue to be supported by the radeon stack; new asics will be supported by the amdgpu stack. CI (Sea Islands) asics have support in both driver stacks, but this is purely for testing purposes. CI parts are officially supported in the radeon stack. Support for CI on the amdgpu stack is determined by a config option in the kernel. CI support is not enabled by default for amdgpu.
Most of our focus has been on Carrizo support, so there are some gaps in the dGPU support for Tonga and Iceland, notably power management. Those gaps will be filled in eventually.
Also included in this code base are full register headers for just about every block on the asics.
Barring the gaps mentioned above, the driver stack is functionally on par with radeon including: - OpenGL 3.3 support using the radeonsi mesa driver - Video decode support using UVD - Video encode support using VCE
The code can be found in the amdgpu branches of the following git trees. xf86-video-amdgpu: http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu mesa: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
To test the new driver stack you will need to specify a device section in your xorg.conf with the driver set to amdgpu rather than radeon.
Please review!
Thanks,
The AMD Linux Driver Team _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Apr 24, 2015 at 9:43 AM, Zhou, Jammy Jammy.Zhou@amd.com wrote:
Hi Alex,
For the core driver patch:
+config DRM_AMDGPU
tristate "AMD GPU"depends on DRM && PCIselect FB_CFB_FILLRECTselect FB_CFB_COPYAREAselect FB_CFB_IMAGEBLITselect FW_LOADERselect DRM_KMS_HELPERselect DRM_KMS_FB_HELPERselect DRM_TTMselect POWER_SUPPLYselect HWMONselect BACKLIGHT_CLASS_DEVICEselect DRM_AMD_GNB_BUSselect INTERVAL_TREEI think DRM_AMD_GNB_BUS is not used, we can probably remove it now.
+/* TODO: Here are things that needs to be done :
- surface allocator & initializer : (bit like scratch reg) should
initialize HDP_ stuff on RS600, R600, R700 hw, well anythings
related to surface
- WB : write back stuff (do it bit like scratch reg things)
- Vblank : look at Jesse's rework and what we should do
- r600/r700: gart & cp
- cs : clean cs ioctl use bitmap & things like that.
- power management stuff
- Barrier in gart code
- Unmappabled vram ?
- TESTING, TESTING, TESTING- */
+/* Initialization path:
- We expect that acceleration initialization might fail for various
- reasons even thought we work hard to make it works on most
- configurations. In order to still have a working userspace in such
- situation the init path must succeed up to the memory controller
- initialization point. Failure before this point are considered as
- fatal error. Here is the init callchain :
amdgpu_device_init perform common structure, mutex initialization
asic_init setup the GPU memory layout and perform all
one time initialization (failure in this
function are considered fatal)
asic_startup setup the GPU acceleration, in order to
follow guideline the first thing this
function should do is setting the GPU
memory controller (only MC setup failure
are considered as fatal)- */
These should be outdated, and I think they can be removed now.
For the uapi header patch:
+#define AMDGPU_TILING_MACRO 0x1 +#define AMDGPU_TILING_MICRO 0x2 +#define AMDGPU_TILING_SWAP_16BIT 0x4 +#define AMDGPU_TILING_R600_NO_SCANOUT AMDGPU_TILING_SWAP_16BIT +#define AMDGPU_TILING_SWAP_32BIT 0x8 +/* this object requires a surface when mapped - i.e. front buffer */ +#define AMDGPU_TILING_SURFACE 0x10 +#define AMDGPU_TILING_MICRO_SQUARE 0x20 +#define AMDGPU_TILING_EG_BANKW_SHIFT 8 +#define AMDGPU_TILING_EG_BANKW_MASK 0xf +#define AMDGPU_TILING_EG_BANKH_SHIFT 12 +#define AMDGPU_TILING_EG_BANKH_MASK 0xf +#define AMDGPU_TILING_EG_MACRO_TILE_ASPECT_SHIFT 16 +#define AMDGPU_TILING_EG_MACRO_TILE_ASPECT_MASK 0xf +#define AMDGPU_TILING_EG_TILE_SPLIT_SHIFT 24 +#define AMDGPU_TILING_EG_TILE_SPLIT_MASK 0xf +#define AMDGPU_TILING_EG_STENCIL_TILE_SPLIT_SHIFT 28 +#define AMDGPU_TILING_EG_STENCIL_TILE_SPLIT_MASK 0xf ...... +#define SI_TILE_MODE_COLOR_LINEAR_ALIGNED 8 +#define SI_TILE_MODE_COLOR_1D 13 +#define SI_TILE_MODE_COLOR_1D_SCANOUT 9 +#define SI_TILE_MODE_COLOR_2D_8BPP 14 +#define SI_TILE_MODE_COLOR_2D_16BPP 15 +#define SI_TILE_MODE_COLOR_2D_32BPP 16 +#define SI_TILE_MODE_COLOR_2D_64BPP 17 +#define SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP 11 +#define SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP 12 +#define SI_TILE_MODE_DEPTH_STENCIL_1D 4 +#define SI_TILE_MODE_DEPTH_STENCIL_2D 0 +#define SI_TILE_MODE_DEPTH_STENCIL_2D_2AA 3 +#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3 +#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
+#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
It looks these definitions are not used by libdrm_amdgpu anymore (and even by the kernel driver). Maybe we can remove the unused definitions, and move the used ones to amdgpu.h instead. Besides, I think we'd better remove 'R600/EG/SI/CIK' from the naming.
The AMDGPU_TILING definitions are used by UMDs to set amdgpu_bo_metadata::tiling_info. I plan to rework them, because they are not sufficient for VI and contain obsolete stuff.
The SI/CIK_TILE_MODE definitions can be removed indeed.
Marek
On Mon, Apr 20, 2015 at 6:33 PM, Alex Deucher alexdeucher@gmail.com wrote:
I'm pleased to announce the initial release of the new amdgpu driver. This is a partial replacement for the radeon driver for newer AMD asics. A number of components are still shared. Here is a comparison of the radeon and amdgpu stacks:
- radeon stack
kernel driver: radeon.ko libdrm: libdrm_radeon mesa: radeon, r200, r300, r600, radeonsi ddx: xf86-video-ati
- amdgpu stack
kernel driver: amdgpu.ko libdrm: libdrm_amdgpu mesa: radeonsi ddx: xf86-video-amdgpu
Older asics will continue to be supported by the radeon stack; new asics will be supported by the amdgpu stack. CI (Sea Islands) asics have support in both driver stacks, but this is purely for testing purposes. CI parts are officially supported in the radeon stack. Support for CI on the amdgpu stack is determined by a config option in the kernel. CI support is not enabled by default for amdgpu.
Most of our focus has been on Carrizo support, so there are some gaps in the dGPU support for Tonga and Iceland, notably power management. Those gaps will be filled in eventually.
Also included in this code base are full register headers for just about every block on the asics.
Barring the gaps mentioned above, the driver stack is functionally on par with radeon including:
- OpenGL 3.3 support using the radeonsi mesa driver
- Video decode support using UVD
- Video encode support using VCE
The code can be found in the amdgpu branches of the following git trees. xf86-video-amdgpu: http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu mesa: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
Some updates on the latest source locations:
xf86-video-amdgpu: http://cgit.freedesktop.org/xorg/driver/xf86-video-amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/amd/drm-amd/ mesa: http://cgit.freedesktop.org/mesa/mesa/log/?h=amdgpu
Alex
To test the new driver stack you will need to specify a device section in your xorg.conf with the driver set to amdgpu rather than radeon.
Please review!
Thanks,
The AMD Linux Driver Team
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Emil Velikov -
Marek Olšák -
Zhou, Jammy