..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

Joseph Mayer
On April 25, 2018 7:08 PM, Jonathan Gray <[hidden email]> wrote:
..

> > The Radeon GPU:s are important in OpenBSD's ecosystem as they are the
> > only way to increase graphics functionality, that not involves changing
> > CPU to Intel's latest, and hence change motherboard and other hardware.
> > Do you have plans to port amdgpu?
> > Would particular hardware donations or other donations be of help?
>
> I have no plans regarding amdgpu.
>
> Most people seem to be interested from the point of view of polaris/vega
> which are not supported in linux 4.4. Ignoring the parts of the shared
> drm/ttm code that would have to be updated the latest
> drivers/gpu/drm/amd in linux has over 1.5 million lines of code. Which
> is multiple times larger than the complete OpenBSD kernel source...

Hi Jonathan,

Thank you for your previous response.

I have talked to Alex Deucher (he's on #radeon FreeNode IRC, agd5f) as
well as hwentlan who both work for AMD in depth about the AMDGPU
driver, and they clarify that this is where AMD will give all future
efforts, so from what I understand over time porting AMDGPU will become
more and more relevant and at some point a pushing priority.

From talking to them, the most important features in AMDGPU appear to
be:

 * GPU scheduler, splits GPU resources between processes
   The GPU scheduler helps load-balance both memory bandwidth and
   rendering work within the GPU between different programs that use 3D
   concurrently, shown on display at same time.

   E.g., say you have two processes submitting work to the GPU. If one
   is submitting work very fast, it's jobs can will get lined up and it
   will monopolize the GPU time if it's first come first server. The
   scheduler makes sure both processes get access to the GPU.

   (No such thing in the old driver)

 * Display handling code (called "DC" in the AMDGPU codebase):
   Lots more display features compared to Radeon: atomic modesetting
   framework on Linux, DP MST, FBC, etc., GPU scheduler, fine grained
   clock and voltage control (similar to wattman in windows), more
   power features supported, etc.

   (DC is the name of the display handling code in AMDGPU.)

 * Fine grained control of the power states (minor tweaks to voltages
   or clocks, etc.)

   (Radeon supported dynamic power management, where the GPU clocks
   could be changed dynamically based on demand, but not fine grained.)

 * Support for MST hubs (so more monitors connected to an MST hub, get
   identified as separate monitors by the computer)

 * 8K monitor support via MST based on 2x displayport connectors

 * DP MST in the old Radeon driver is experimental and doesn't work
   that well, in AMDGPU done well.

 * DRM sync objects support, which enabled a bunch of OGL and EGL
   extensions

 * AMDGPU may get support for freesync/adaptive sync/vrr in the future
   and in the more distant future support for HDR, as in up to 16 bits
   per color.

   hwentlan explains, "for the consumer it means that brights are
   brighter, darks are darker, and you still see tons of details in the
   shadows, even though your screen might show you glare in other
   areas. There are many different HDR formats and ways of tonemapping
   image data into those formats. This requires new interfaces between
   kernel and user-mode, and requires the kernel display driver to
   understand and be able to program the HW to output the required
   formats".

Joseph

Reply | Threaded
Open this post in threaded view
|

Re: ..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

Chris Cappuccio
> > Ignoring the parts of the shared
> > drm/ttm code that would have to be updated the latest
> > drivers/gpu/drm/amd in linux has over 1.5 million lines of code. Which
> > is multiple times larger than the complete OpenBSD kernel source...
>

Despite everything you replied with, Jonathan's reply still accurately
details the overriding concern.

The code base is so huge, not only is porting a herculean task, but who wants
this much code in their kernel to run the...video card?

As a matter of fact, the existing AMD code can be extended to support the newer
hardware without the huge import.

Realistically, neither porting amdgpu nor extending the existing code are going
to happen any time soon. There's no straightforward path to solve this problem.