R600 Gallium3D Driver Is Now Built By Default

[89c51]

G3D is supposed to be a cross OS solution to the graphics problem. How come its so dependent on linux stuff that need to be ported on other OSes???






ps
someone must give marek a big lump of money

[allquixotic]

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.

Indeed, and I don't blame corporations for not wanting to invest engineers in doing the work. I won't deny that BSD has its adherents, and they might have a valid point when it comes to server-based work, but for clients with rich 3d and such, BSD wouldn't be my first choice, especially if you're looking for free drivers (nvidia blob is supported on FreeBSD afaik, so you've at least got that).

To change the situation, some company (or extremely motivated volunteer) would have to take the work upon themselves. I don't see it getting done otherwise. And with Linux's open source graphics stack shaping up so well, they have a free software competitor, making it even less likely that there will necessarily be a second (especially if their goal is to "play catchup" with Linux; if they plan to do something radically new and better, that might be a different story.)

[smitty3268]

G3D is supposed to be a cross OS solution to the graphics problem. How come its so dependent on linux stuff that need to be ported on other OSes???

The state trackers in G3D are cross platform, the rest is not. There is a whole winsys layer defined in gallium that hooks into the native OS calls.

The (correct) way of accessing actual hardware is to do it in the kernel, and every kernel is different. You can come up with a big compatibility layer that your kernel driver sits in, like the nvidia and fglrx drivers do, but that's a fair amount of work to do which not many are really interested in. The main bits that have to be implemented within the kernel itself are the memory manager - the GEM and TTM APIs. Once they are provided, the rest of the kernel drivers should be pretty simple to port over.

[89c51]

The state trackers in G3D are cross platform, the rest is not. There is a whole winsys layer defined in gallium that hooks into the native OS calls.

The (correct) way of accessing actual hardware is to do it in the kernel, and every kernel is different. You can come up with a big compatibility layer that your kernel driver sits in, like the nvidia and fglrx drivers do, but that's a fair amount of work to do which not many are really interested in. The main bits that have to be implemented within the kernel itself are the memory manager - the GEM and TTM APIs. Once they are provided, the rest of the kernel drivers should be pretty simple to port over.

thanks

the question is more about why it can't use the OS native memory manager and requires GEM TTM or whatever linux tech. is it just easier to port those instead of adapting the native ones???

[yotambien]

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.

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.

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.

Indeed, and I don't blame corpor

"Indeed"? Indeed what? Indeed your cheap shot at BSD was unfounded?

[Pulsewidth]

This is bad news, because contrary to the article's assertion Gallium is still a piece of crap. I'm using a Radeon 4850 and Xorg-edgers PPA on Ubuntu Natty, and I get rock solid 120fps (on my 120Hz LCD) on most OpenArena maps using Mesa classic, but on Gallium it averages about 40fps. Completely unacceptable.

This is an improvement over the 20fps I got a few months ago, but still completely unacceptable. It also suggests the easy optimizations are already done, so I don't have any hope that Gallium will ever match Mesa classic.

[allquixotic]

"Indeed"? Indeed what? Indeed your cheap shot at BSD was unfounded?

No, "indeed" that it would be a lot of work. And now, "indeed" that your cheap shot at me was unfounded.

I never said it would be easy, just that it would be easier if the licenses were compatible. Well, the licenses are in fact compatible, as I'm now learning -- but even despite that fact, it's obvious to anyone who's written any code at all (*raises hand*) that it wouldn't be a simple port.

That it would be a difficult job isn't a stab at BSD, that's just a technical fact. It is a stab at BSD to say that their small desktop user-base, coupled with low corporate investment in the desktop side of BSD, makes it unlikely that this non-trivial task will be completed in due course. It'll probably be one of those side projects that putters along at a snail's pace, even compared to the Linux graphics effort.

Of course, as a user and promoter of a minority OS already (Linux), it's not hard to at least sympathize with BSD for being in a similar situation, just further down on the totem pole. Just as desktop Linux has a "chicken and egg" problem with getting hardware support, apps, etc. to our platform to convert users, so does desktop BSD have a similar problem if they intend to convert folks from any other platform. Although their toughest competitor is probably Linux; imho BSD is a significant improvement over Windows because it's open source

[yotambien]

No, "indeed" that it would be a lot of work. And now, "indeed" that your cheap shot at me was unfounded.

Heh, no...

[airlied]

thanks

the question is more about why it can't use the OS native memory manager and requires GEM TTM or whatever linux tech. is it just easier to port those instead of adapting the native ones???

There is no native graphics memory manager in any other OS. hence why you have to implement GEM/TTM, which are a graphics memory manager. Implementing an alternative is also acceptable but since the feature set requires is equivalent, porting makes more sense.

Then you get to interface the GPU memory manager to the native CPU memory management and you lose 6 months.

Dave.

[smitty3268]

thanks

the question is more about why it can't use the OS native memory manager and requires GEM TTM or whatever linux tech. is it just easier to port those instead of adapting the native ones???

See http://lwn.net/Articles/257417/ for some details about how GPU addressable memory can have quite different requirements than standard RAM. Such details could be handled individually inside each driver, but for better portability they tried to come up with a generic system (TTM) and then Intel created another one they felt met their needs better (GEM).