On April 25, 2018 7:08 PM, Jonathan Gray <j...@jsg.id.au> 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
