Open-Source AMD Linux Developers Already Thinking About API Improvements

[bridgman]

More or less yes abandoning r600/radeonsi that means because it is pretty much finished, it may sound (not) funny because most users use that right now but that is how developing is done , when you finish building one house you start build another .

The best thing i expect from devs will be, to not broke previous houses while bulding new

Except (a) we are not abandoning radeonsi AFAIK and (b) r600g is already "abandoned" to use your terminology (since all our recent chips use radeonsi) but it has continued to improve.

[pal666]

While I understand most of the reasons why, it's seems kinda stupid to me to force the "mainline" stuff to maintain API compatibility... forever. That's just asking for complicated, nasty code (X.org, anybody?).

I've always personally been a fan of the "2 major version rule". As in, any feature introduced in, say, version 3.0, must remain in the code for compatibility reasons until at least version 5.0. Hopefully, by that time, anybody depending on the feature/API/whatever you wish to remove will have removed the dependency and most likely moved to a newer/better thing that you offer. That doesn't mean you should break your code or rewrite everything every two major versions, but it allows for some flexibility when it comes to features and other things you wish to remove.

in our context it means linux 3.0/5.0

[dungeon]

Except (a) we are not abandoning radeonsi AFAIK and (b) r600g is already "abandoned" to use your terminology (since all our recent chips use radeonsi) and it keeps improving.

Yes i understand what abandoning means, i already survive DRI1>DRI2 so UMS>KMS honky>ponky times with r200 driver years ago, so i pretty much know what that means .

Yes abandoning complitely not, but more or less that is it

[bridgman]

If you agree that "more or less" and "not at all" are equivalent, I guess I agree with what you are saying

[Prescience500]

Speaking of dri, I wonder whether the new driver will use tried and true dri2 or the newer dri3 in order to give tear free graphics.

[jrch2k8]

well, bridgman correct me if my logic is wrong here:

announcements:

a) we will not open catalyst code <-- fair enough nobody want that mess in the kernel and prolly will take a decade to get upstream anyway
b) use the new amdgpu kernel driver
c) train our guys to work in opensource,etc.
d) DPM current code in the OSS kernel driver is up to par with catalyst(marek i believe)
e) VCE is pretty much done,etc.

Sooooo, i assume nobody on AMD is such a giant idiot to go and rewrite a kernel driver that is pretty close in features to catalyst and is already opensource <-- based on this logic i will assume you what you guys mean is to take the current radeonsi kernel driver(assuming is not common to radeonsi and r600g) do some optimizations and refactoring where needed, rename it, add some pipework for mutable userspaces and enjoy.

if this is the actual case i assume the catalyst userspace driver will prolly support only very recent hardware as michael suspects but with the opensource userspace nothing should change beyond requiring a higher kernel version(3.20 prolly) and the appropiate fixes to use the new features in mesa and family, am i right?

[kalrish]

Am I the only one - especially as a "pretty-expensive-290" owner - a bit afraid that the radeonsi will be forgotten between two major drivers? The original radeon driver is more or less "done", except perhaps better OpenGL support. The performance is pretty good, and the tweaks that can be made to it are not that huge.
But the RadeonSI is still in need of pretty much development and stabilizing, especially the Hawaii family of ASICS. I am a bit afraid that most AMD developers will now jump on the amdgpu bandwagon, abandoning radeonsi.

(This is my understanding on the matter. Please, correct me if it's wrong.)

In Mesa-Gallium3D, APIs such as OpenGL and OpenCL, among others, are implemented in state trackers, which turn API-specific concepts into generic ones. Then, hardware device drivers, which are API-agnostic, turn that intermediate representation into hardware-specific commands. Finally, the WinSys part sends such commands to the hardware using OS-specific APIs - in Linux, the libdrm_* interfaces: libdrm_radeon for the Radeon DRM driver, libdrm_nouveau for the Nouveau one, etc. There are some cases in which the hardware device driver is not involved, such as allocating buffers: for that, the state tracker talks to the WinSys directly.


The official Intel Mesa drivers are old-style, whereas r600 and radeonsi are Gallium3D hardware device drivers.


Gallium3D hardware device drivers do not depend on particular APIs nor OS hardware interfaces; their task is mainly to translate TGSI IR (which is produced and maintained by state trackers) to GPU code (which is uploaded to the hardware with the WinSys).

As a new kernel module is introduced, the following changes will have to be made:

• a new libdrm library that is able to communicate with it, libdrm_amdgpu, will have to be added in libdrm
• a new WinSys component that uses libdrm_amdgpu will have to be added in Mesa, in the existing Gallium3D infrastructure

radeonsi, which is a Gallium3D hardware device driver, will not be abandoned. It does not know about APIs or kernel interfaces; it just translates the generic commands with which it is fed into chip-specific code, without worrying where they came from (OpenGL, OpenGL ES,...) or how to upload them (libdrm_radeon, libdrm_amdgpu,...). Thus, it will only be changed to support translating Gallium3D's generic representation, TGSI, to the ISA of the new GPUs (Pirate Islands, I believe).

See the Wikipedia article on Gallium3D.

TL;DR: radeonsi won't be abandoned. It will be used for the next GPUs and will continue to be improved.

[Kivada]

[Azpegath]

(This is my understanding on the matter. Please, correct me if it's wrong.)

In Mesa-Gallium3D, APIs such as OpenGL and OpenCL, among others, are implemented in state trackers, which turn API-specific concepts into generic ones. Then, hardware device drivers, which are API-agnostic, turn that intermediate representation into hardware-specific commands. Finally, the WinSys part sends such commands to the hardware using OS-specific APIs - in Linux, the libdrm_* interfaces: libdrm_radeon for the Radeon DRM driver, libdrm_nouveau for the Nouveau one, etc. There are some cases in which the hardware device driver is not involved, such as allocating buffers: for that, the state tracker talks to the WinSys directly.


The official Intel Mesa drivers are old-style, whereas r600 and radeonsi are Gallium3D hardware device drivers.


Gallium3D hardware device drivers do not depend on particular APIs nor OS hardware interfaces; their task is mainly to translate TGSI IR (which is produced and maintained by state trackers) to GPU code (which is uploaded to the hardware with the WinSys).

As a new kernel module is introduced, the following changes will have to be made:

• a new libdrm library that is able to communicate with it, libdrm_amdgpu, will have to be added in libdrm
• a new WinSys component that uses libdrm_amdgpu will have to be added in Mesa, in the existing Gallium3D infrastructure

radeonsi, which is a Gallium3D hardware device driver, will not be abandoned. It does not know about APIs or kernel interfaces; it just translates the generic commands with which it is fed into chip-specific code, without worrying where they came from (OpenGL, OpenGL ES,...) or how to upload them (libdrm_radeon, libdrm_amdgpu,...). Thus, it will only be changed to support translating Gallium3D's generic representation, TGSI, to the ISA of the new GPUs (Pirate Islands, I believe).

See the Wikipedia article on Gallium3D.

TL;DR: radeonsi won't be abandoned. It will be used for the next GPUs and will continue to be improved.

Thank you for the great walkthrough!

And also thanks to Bridgman for clearing things up as well!

[tmpdir]

well, bridgman correct me if my logic is wrong here:

announcements:

a) we will not open catalyst code <-- fair enough nobody want that mess in the kernel and prolly will take a decade to get upstream anyway
b) use the new amdgpu kernel driver
c) train our guys to work in opensource,etc.
d) DPM current code in the OSS kernel driver is up to par with catalyst(marek i believe)
e) VCE is pretty much done,etc.

Sooooo, i assume nobody on AMD is such a giant idiot to go and rewrite a kernel driver that is pretty close in features to catalyst and is already opensource <-- based on this logic i will assume you what you guys mean is to take the current radeonsi kernel driver(assuming is not common to radeonsi and r600g) do some optimizations and refactoring where needed, rename it, add some pipework for mutable userspaces and enjoy.

if this is the actual case i assume the catalyst userspace driver will prolly support only very recent hardware as michael suspects but with the opensource userspace nothing should change beyond requiring a higher kernel version(3.20 prolly) and the appropiate fixes to use the new features in mesa and family, am i right?

After assuming an asumption based on an assumption derived from the assumtion as michaels suspections I assume that the chance you are right is rather slim