> > 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...
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
* 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
* 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
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
Re: ..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
> > 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.