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.
..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
On April 25, 2018 7:08 PM, Jonathan Gray 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
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
I have a FirePro V5900 (Cayman part from the Northern Islands family) which I run with EXA acceleration on 6.2. H264 video with a resolution of 3840x2160 and 25fps play flawlessly with the OpenGL acceleration in mpv (on a WSXGA+ display). Ostensibly this card can drive UHD monitors at their native refresh rate that support the MST mode (two virtual panels at 1920x2160), while its longer brother, the V7900, can do SST mode. -- Patrick Harper paia...@fastmail.com On Sat, 28 Apr 2018, at 11:00, Joe Gidi wrote: > > On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote: > >> > >> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote: > >> >> 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... > >> > >> Thanks for this update! > >> > >> Just to clarify, before I spend a bunch of money on new hardware, should > >> I > >> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort > >> with > >> this updated driver? > >> > >> Thanks again, > > > > It appears that 'R7 250' can mean either a cape verde or oland radeon > > depending on the model. Both are GCN parts. > > > > 4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0 > > Both claim support for displayport 1.2 which should be able to do > > 4k 60Hz. HDMI 2.0 seems to only be on later hardware with DCE >= 11 > > carrizo (not carrizo-l which is mullins), polaris etc. > > > > With the low end radeons displayport is sometimes only available on > > oem models of cards sold as options for systems marketed as business > > desktops or workstations. > > > > And as mentioned earlier for acceleration you'll currently have to build > > a different version of Mesa than what OpenBSD releases/snapshots ship > > with. > > Hi Jonathan, > > Thanks for the detailed answer! > > As best I can tell from wading through the mess of marketing names and > specifications, accelerated 4k video is currently not an option with > Radeon cards; the older cards don't support high-enough resolutions, and > the newer ones don't have acceleration support yet due to the Mesa > problem. Looks like I might need to buy an Intel machine or wait for the > Mesa issues to get resolved. > > Thanks again, > Joe > > > -- > > Joe Gidi > j...@entropicblur.com > > "You cannot buy skill." -- Ross Seyfried >
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
> On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote: >> >> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote: >> >> 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... >> >> Thanks for this update! >> >> Just to clarify, before I spend a bunch of money on new hardware, should >> I >> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort >> with >> this updated driver? >> >> Thanks again, > > It appears that 'R7 250' can mean either a cape verde or oland radeon > depending on the model. Both are GCN parts. > > 4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0 > Both claim support for displayport 1.2 which should be able to do > 4k 60Hz. HDMI 2.0 seems to only be on later hardware with DCE >= 11 > carrizo (not carrizo-l which is mullins), polaris etc. > > With the low end radeons displayport is sometimes only available on > oem models of cards sold as options for systems marketed as business > desktops or workstations. > > And as mentioned earlier for acceleration you'll currently have to build > a different version of Mesa than what OpenBSD releases/snapshots ship > with. Hi Jonathan, Thanks for the detailed answer! As best I can tell from wading through the mess of marketing names and specifications, accelerated 4k video is currently not an option with Radeon cards; the older cards don't support high-enough resolutions, and the newer ones don't have acceleration support yet due to the Mesa problem. Looks like I might need to buy an Intel machine or wait for the Mesa issues to get resolved. Thanks again, Joe -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
On 04/25/18 17:34, mazocomp wrote: On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote: 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... Wow, this driver is fatter than elephant. Anyway, thank you for updating radeondrm(4), now I can use my PC with Kaveri APU. Updating to the latest snapshot and the same (good) results. the HDMI/VGA outputs are detected and changing the brightness is working on my Lenovo G50-45 (AMD A8-6410 with AMD Radeon R5 Graphics[1]). Thank you :-) [1]: http://dmesgd.nycbug.org/index.cgi?do=view&id=3586
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote: > > > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote: > >> 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... > > Thanks for this update! > > Just to clarify, before I spend a bunch of money on new hardware, should I > be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort with > this updated driver? > > Thanks again, It appears that 'R7 250' can mean either a cape verde or oland radeon depending on the model. Both are GCN parts. 4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0 Both claim support for displayport 1.2 which should be able to do 4k 60Hz. HDMI 2.0 seems to only be on later hardware with DCE >= 11 carrizo (not carrizo-l which is mullins), polaris etc. With the low end radeons displayport is sometimes only available on oem models of cards sold as options for systems marketed as business desktops or workstations. And as mentioned earlier for acceleration you'll currently have to build a different version of Mesa than what OpenBSD releases/snapshots ship with.
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
I have a response from an anon poster on the Linux sub on Reddit that may or may not be well informed (take it with a pinch of salt), but their posts were ostensibly more popular than my queries about amdgpu's mooted bloat, is there anyone here who can make sense of their points as to their legitimacy? >That's nothing. First of all, majority of it is in header files as >initialization data and various tables, and the second thing is that > it's >more compartmentalized as compared to radeon (read: there is a lot of >duplication). > >Memory wise, the cost of the 'bloat' is laughable. And code path wise it's >quite comparable to radeon. You don't execute every > single byte of code >just because it's there. You hit some code paths often, some rarely, and some >never. Critical paths are the > ones you want to optimize the hell out of. > >Code bloat is a different thing. Usually it refers to layers upon layers of >abstraction and crufty interfaces that no longer really > fit, but are kept >for various compatibility/legacy reasons. And even then, it doesn't >necessarily translate to performance > penalties. Usually bloat is >something that hits developers rather than users, since large messy codebase >is difficult to> maintain. > >P.S. There is nothing in modern AMD GPUs that makes them unsupportable by >older radeon driver per se, specs are > completely open, >nothing prevents you from coming up with your own 'slim' driver. It's just >that it has been decided that, > moving on, new hardware support will be >added to amdgpu only. The size of amdgpu results from deliberate architectural >> approaches. > >First rule of any optimization every dev should know: profile, profile, >profile! Without careful measurements you cannot make > proper assessment of >performance, even very experienced devs get bit by that when making casual >assessments. > >If you feel you can trim it down, you're welcome to remove code you deem >unnecessary and submit patches to the tree. Those of us who have a bloaty mainstream browser with Javascript enabled can read the whole exchange at https://www.reddit.com/r/Amd/comments/7u54d3/lisa_su_we_are_ramping_production_of_gpus/dtkcysq/?context=3 -- Patrick Harper paia...@fastmail.com
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
On Wed, Apr 25 2018, Jonathan Gray wrote: [...] > 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... Made my day... -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote: > 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... > Wow, this driver is fatter than elephant. Anyway, thank you for updating radeondrm(4), now I can use my PC with Kaveri APU.
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
On Wed, Apr 25, 2018 at 03:10:15AM -0400, Joseph Mayer wrote: > Hi! > > Radeon drivers are specific per Radeon microarchitecture and Radeon > microarchitecture version. > > The Radeon microarchitectures to date are TS 1, TS 2, TS 3, GCN 1, GCN > 2, GCN 3, GCN 4, GCN 5 (TS = TeraScale and GCN = Graphics Core Next), > in that ascending chronological order. [1] Terascale is r600, so there are more than just that. The drivers in Mesa are radeon (r100), r200, r300, r600, radeonsi. > > > First, thank you very much jsg@ for that you committed full OpenBSD > kernel support for the radeondrm(4) driver today! [2] > > Previously, while Xorg's radeondrm(4) driver supported all cards up to > GCN 2, OpenBSD's kernel supported the Radeons up to GCN 1 only. The > radeon(4) man page listed all cards up to GCN 2, but only the cards up > to GCN 1 were actually supported by OpenBSD. > > jsg@'s diff today extends radeondrm(4) to support Radeons up to GCN 2. It is worth reiterating that there is no self contained 2d acceleration in the xorg driver for GCN/radeonsi parts. Acceleration is only via glamor and requires Mesa to work. The radeonsi driver in Mesa is not built as it has build time and run time dependencies on libLLVM and libelf which are not in src or xenocara. And to use libLLVM from LLVM 6.0 a newer version of Mesa than what is in the xenocara tree is required (ie 17.3). Mesa 17.x triggers some kind of graphical corruption on Intel hardware for reasons still unclear so xenocara remains on Mesa 13.0.6. > > > The major move with Radeon graphics cards today, is their move from the > radeondrm(4) driver (called "xf86-video-ati" by Xorg and "radeon" on > Linux) [3], to the "amdgpu" driver (called "xf86-video-amdgpu" by Xorg) > [4]. > > All new Radeon are driven by the amdgpu driver: > > The radeondrm driver supports all Radeon cards up to and including GCN > 2. GCN 2 was released 2013 and the last GCN 2 card was released 2015. > No more GCN 2 cards will be coming. Parts get rebadged through multiple generations of marketing names, especially on the low end. > > The amdgpu driver supports all new Radeon cards from GCN 1.2 and up. There are build time options for 'enable experimental support for SI asics' and 'enable support for CIK asics' which seem to not be the default. > > This means the amdgpu driver is needed for GCN 3 and newer Radeons, and > GCN 3 cards started coming to the market 2014. > > amdgpu(4) has not been ported to OpenBSD yet. [5] > > > I am not perfectly clear about the max feature set in the GCN 2 cards, > maybe I will make a post later about what you can and cannot do with > amdgpu(4) (not yet ported) vs. radeondrm(4) cards, however more modern > features like Displayport 1.4 and 1.3 support, support for higher > resolutions, MST (Multi-Stream Transport), newer video codecs with > higher resolutions etc., appear to be only in the newer GCN 5 and GCN 4 > cards, which are supported only by the amdgpu driver. There are MST parts in radeondrm though they may be experimental. Many of the GCN parts covered by radeondrm are advertised as being able to support 4k SST/MST on displayport. > > 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...
Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
Hi! Radeon drivers are specific per Radeon microarchitecture and Radeon microarchitecture version. The Radeon microarchitectures to date are TS 1, TS 2, TS 3, GCN 1, GCN 2, GCN 3, GCN 4, GCN 5 (TS = TeraScale and GCN = Graphics Core Next), in that ascending chronological order. [1] First, thank you very much jsg@ for that you committed full OpenBSD kernel support for the radeondrm(4) driver today! [2] Previously, while Xorg's radeondrm(4) driver supported all cards up to GCN 2, OpenBSD's kernel supported the Radeons up to GCN 1 only. The radeon(4) man page listed all cards up to GCN 2, but only the cards up to GCN 1 were actually supported by OpenBSD. jsg@'s diff today extends radeondrm(4) to support Radeons up to GCN 2. The major move with Radeon graphics cards today, is their move from the radeondrm(4) driver (called "xf86-video-ati" by Xorg and "radeon" on Linux) [3], to the "amdgpu" driver (called "xf86-video-amdgpu" by Xorg) [4]. All new Radeon are driven by the amdgpu driver: The radeondrm driver supports all Radeon cards up to and including GCN 2. GCN 2 was released 2013 and the last GCN 2 card was released 2015. No more GCN 2 cards will be coming. The amdgpu driver supports all new Radeon cards from GCN 1.2 and up. This means the amdgpu driver is needed for GCN 3 and newer Radeons, and GCN 3 cards started coming to the market 2014. amdgpu(4) has not been ported to OpenBSD yet. [5] I am not perfectly clear about the max feature set in the GCN 2 cards, maybe I will make a post later about what you can and cannot do with amdgpu(4) (not yet ported) vs. radeondrm(4) cards, however more modern features like Displayport 1.4 and 1.3 support, support for higher resolutions, MST (Multi-Stream Transport), newer video codecs with higher resolutions etc., appear to be only in the newer GCN 5 and GCN 4 cards, which are supported only by the amdgpu driver. 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? Thanks, Joseph [1] https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units https://en.wikipedia.org/wiki/Radeon https://www.x.org/wiki/RadeonFeature/ [2] https://marc.info/?t=15166466154&r=1&w=2 [3] http://man.openbsd.org/OpenBSD-6.3/radeon.4 https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/ https://www.mankier.com/4/radeon https://manpages.debian.org/stretch/xserver-xorg-video-radeon/radeon.4.en.html [4] https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-Accepted https://cgit.freedesktop.org/xorg/driver/xf86-video-amdgpu/tree/ https://en.wikipedia.org/wiki/AMDGPU https://www.x.org/wiki/RadeonFeature/ https://www.mankier.com/4/amdgpu https://manpages.debian.org/stretch/xserver-xorg-video-amdgpu/amdgpu.4.en.html [5] Those I talked to clarified this however also relevant refs: As seen by the absence of any "amdgpu" man page: http://man.openbsd.org/OpenBSD-6.3/amdgpu No "xf86-video-amdgpu" directory among the Xenocara drivers: https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/ As of today on misc@ "amdgpu" has only been mentioned once, which was in the context of not being supported: https://marc.info/?t=15166466154&r=1&w=2
