R600 Gallium3D Driver Is Now Built By Default

[phoronix]

Phoronix: R600 Gallium3D Driver Is Now Built By Default

Marek Olšák, the open-source community developer known for his contributions to Mesa / Gallium3D and to the Radeon driver in particular, has submitted a set of patches to the Mesa mailing list. This time around, these patches overhaul the Gallium3D configure/build-time options. These patches are meant to make it easier to configure Gallium3D with the Gallium3D EGL support and in automatically determining what state trackers to build. In addition, there is one prominent change in default behavior...

http://www.phoronix.com/vr.php?view=OTU2OQ

[allquixotic]

It's high time to nuke r300c/r600c from the repositories altogether. All the effort put into them is appreciated, and they served their purpose, but they are just a maintenance burden now.

They will stay in the git history regardless, so it's not like the code will go away. Nuking stuff in a version-controlled world is a pretty safe operation.

Intel made a similar move when they pared down all the legacy support for UMS, EXA, XAA, etc. in the intel driver stack. If it hasn't been done, UMS and XAA support in radeon should also be removed. Just keep the path that's known to work and actively being worked on: KMS + GEM/TTM + DRI2 + EXA + r600g.

[Prescience500]

Now we just need Intel to make the switch. Then we can ditch the classic architecture completely.

[smitty3268]

It's high time to nuke r300c/r600c from the repositories altogether. All the effort put into them is appreciated, and they served their purpose, but they are just a maintenance burden now.

They will stay in the git history regardless, so it's not like the code will go away. Nuking stuff in a version-controlled world is a pretty safe operation.

Intel made a similar move when they pared down all the legacy support for UMS, EXA, XAA, etc. in the intel driver stack. If it hasn't been done, UMS and XAA support in radeon should also be removed. Just keep the path that's known to work and actively being worked on: KMS + GEM/TTM + DRI2 + EXA + r600g.

I tend to agree, especially since the classic drivers aren't supported much anymore. r300c bugs, at least, have been closed with the response that the user should switch to the gallium driver. It sucks that the BSDs can't run them yet, but at some point you've just got to cut your losses and move on in order to make progress.

[allquixotic]

I tend to agree, especially since the classic drivers aren't supported much anymore. r300c bugs, at least, have been closed with the response that the user should switch to the gallium driver. It sucks that the BSDs can't run them yet, but at some point you've just got to cut your losses and move on in order to make progress.

Any other non-Linux kernels wanting to use Mesa + Xorg should seriously consider implementing the kernel-side of the house that it depends on. I know there's work going on in some variants of BSD to do that, but obviously since their platform has considerably lower adoption in desktop circles than Linux, they have less interest and correspondingly fewer developers and testers.

Mesa is user-space software that just so happens to depend on a fairly particular kernel-space implementation, but nothing's stopping anyone from implementing the KMS+GEM+TTM+DRM bits that it needs.

[Plombo]

Any other non-Linux kernels wanting to use Mesa + Xorg should seriously consider implementing the kernel-side of the house that it depends on. I know there's work going on in some variants of BSD to do that, but obviously since their platform has considerably lower adoption in desktop circles than Linux, they have less interest and correspondingly fewer developers and testers.

Mesa is user-space software that just so happens to depend on a fairly particular kernel-space implementation, but nothing's stopping anyone from implementing the KMS+GEM+TTM+DRM bits that it needs.

Implementing the kernel-side graphics stack in other kernels is so much work that no one wants to do it.

[smitty3268]

Implementing the kernel-side graphics stack in other kernels is so much work that no one wants to do it.

Well, the alternative is implementing and maintaining the entire graphics stack. Or at least it will be when r300c and r600c get dropped.

[allquixotic]

Implementing the kernel-side graphics stack in other kernels is so much work that no one wants to do it.

Well, if they'd just use a GPLv2-compatible license, they could use the Linux kernel sources as a reference, and maybe even copy and paste large swaths of code and just adapt the kernel API calls as appropriate to the local dogma.

But aside from that, there are plenty of docs out there that you can use to work on a clean-room implementation of the kernel side. There should be a lot of motivation to do that, considering that as soon as you implement the kernel side of the DRI2 / DRM calls coming out of Mesa, you basically get an OpenGL 2.1 implementation for free.

[Plombo]

Well, if they'd just use a GPLv2-compatible license, they could use the Linux kernel sources as a reference, and maybe even copy and paste large swaths of code and just adapt the kernel API calls as appropriate to the local dogma.

But aside from that, there are plenty of docs out there that you can use to work on a clean-room implementation of the kernel side. There should be a lot of motivation to do that, considering that as soon as you implement the kernel side of the DRI2 / DRM calls coming out of Mesa, you basically get an OpenGL 2.1 implementation for free.

Unlike most of the Linux kernel, the kernel DRM sources are licensed under an MIT/X11 license, which is compatible with the BSD licenses. Even with that, porting all of it to BSD is a task that would take several months.

[bridgman]

Well, if they'd just use a GPLv2-compatible license, they could use the Linux kernel sources as a reference, and maybe even copy and paste large swaths of code and just adapt the kernel API calls as appropriate to the local dogma.

But aside from that, there are plenty of docs out there that you can use to work on a clean-room implementation of the kernel side. There should be a lot of motivation to do that, considering that as soon as you implement the kernel side of the DRI2 / DRM calls coming out of Mesa, you basically get an OpenGL 2.1 implementation for free.

As plombo said, the graphics driver stack is X11 licensed in order to be license-compatible with a wide range of OSes, so there are no license problems. The issue as I understand it is that the OS memory management mechanisms are significantly different between Linux and BSD, so porting the new (and more complex) GEM/TTM graphics memory manager to an OS with a different memory management model is a fair chunk of work.