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
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Joseph Mayer
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=151664661500004&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=151664661500004&r=1&w=2

Reply | Threaded
Open this post in threaded view
|

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

Jonathan Gray-11
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...

Reply | Threaded
Open this post in threaded view
|

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

Leonid Bobrov
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.

Reply | Threaded
Open this post in threaded view
|

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

Jeremie Courreges-Anglas-2
In reply to this post by Jonathan Gray-11
On Wed, Apr 25 2018, Jonathan Gray <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Patrick Harper
In reply to this post by Leonid Bobrov
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
  [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Jonathan Gray-11
In reply to this post by Leonid Bobrov
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.

Reply | Threaded
Open this post in threaded view
|

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

Bijan Ebrahimi
In reply to this post by Leonid Bobrov
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

Reply | Threaded
Open this post in threaded view
|

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

Joe Gidi
In reply to this post by Jonathan Gray-11
> 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
[hidden email]

"You cannot buy skill." -- Ross Seyfried

Reply | Threaded
Open this post in threaded view
|

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

Patrick Harper
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
  [hidden email]

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
> [hidden email]
>
> "You cannot buy skill." -- Ross Seyfried
>