R600 Gallium3D Driver Is Now Built By Default

[yotambien]

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

I don't think we understood each other very well. I know what your "indeed" referred to. What I was trying to say is that you dodged the question of the license once other people pointed out the inaccuracy of your assertion. My impression was that your point was yet another "my license is bigger than your license" kind of argument we see all too often over here. Now that you explained it I realise I did not get your point properly. For the reasons you mention in your last paragraph, I find that constant BSD bitching completely ridiculous.

Then, I'd say it doesn't take a computer genius to guess that implementing or porting all this stuff must be a tremendous amount of work--how long did it took the linux devs to do it?

PS. It's easier to follow the conversation if you write a new post rather than edit a past one. I almost missed your addendum, risking to run into perpetual, internet hate towards each other.

[pingufunkybeat]

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.

I know that people hate this answer, but you must be doing something wrong. What you're describing was the state from 8 months ago. Since then, r600g became almost 2x as fast as classic mesa.

Are you absolutely sure that you're using recent (e.g. today's) git code and not some ancient packaged version?

[89c51]

thanks internet people (dave & smitty3268)

[Pulsewidth]

I know that people hate this answer, but you must be doing something wrong. What you're describing was the state from 8 months ago. Since then, r600g became almost 2x as fast as classic mesa.

Are you absolutely sure that you're using recent (e.g. today's) git code and not some ancient packaged version?

You're right, the Xorg-edgers PPA renamed the LIBGL_DRIVERS_PATH and I didn't notice. Gallium is actually the fast one, and the slow one is the indirect rendering fallback. Classic Mesa is somewhat slower than Gallium.

[mattst88]

You're right, the Xorg-edgers PPA renamed the LIBGL_DRIVERS_PATH and I didn't notice. Gallium is actually the fast one, and the slow one is the indirect rendering fallback. Classic Mesa is somewhat slower than Gallium.

Wouldn't it have been easier to spend 5 minutes debugging (and fixing, since it was so simple) the problem instead of complaining on the internet?

[»John«]

I know that people hate this answer, but you must be doing something wrong. What you're describing was the state from 8 months ago. Since then, r600g became almost 2x as fast as classic mesa.

Are you absolutely sure that you're using recent (e.g. today's) git code and not some ancient packaged version?

You're right, the Xorg-edgers PPA renamed the LIBGL_DRIVERS_PATH and I didn't notice. Gallium is actually the fast one, and the slow one is the indirect rendering fallback. Classic Mesa is somewhat slower than Gallium.

Wouldn't it have been easier to spend 5 minutes debugging (and fixing, since it was so simple) the problem instead of complaining on the internet?

The real problem is that sometimes you can't see the sign staring you right in the face without a hint from someone with a fresh perspective. Also note that he wasn't even close to actually bitching and for all we know, what he said could well be a reality on some quirky piece of crap.

[ahlaht]

I get rock solid 120fps (on my 120Hz LCD) on most OpenArena maps using Mesa classic, but on Gallium it averages about 40fps.

for all we know, what he said could well be a reality on some quirky piece of crap.

I just might have that piece of crap hardware right here. There have been so many bugs specific to this hardware. They are now mostly fixed, but such low FPS seemed very familiar so I started thinking: Perhaps r600c really is faster? I installed OpenArena and started testing with various settings (swapbufferswait, colortiling, dynpm/high/low). It turned out Gallium really is faster, but...

I haven't had any stability issues recently so I really wasn't excepting any. Nevertheless OpenArena crashed 2 times while I was testing. The first crash occurred when I was in console trying to turn FPS meter on. The 2nd crash may have been during game play. I had never played OpenArena before so I don't know if it's just buggy, but I suspect no?

Now while I was initially writing this I wanted to test OpenArena once more to confirm. And I had a 3rd crash. This time it was a total system lockup. No SSH. No logs. Nothing. It occurred during mode switch from 1024x768 to 1024x768 in OpenArena setup. I basically set the same (Very High QL) settings I already had and clicked Accept and display went blank.

I suspect power_profile dynpm could have something to do with this as I never had it enabled for longer periods before.

I'm not going to open a bug until/unless I find the time to investigate this more, but here is my info anyway:
HD5650 / 2.6.39.1 / drm 2.4.26 / mesa 2f0b44f / xorg 1.10.2 / ddx 41eb1fb

[przemoli]

The thing with GEM + TTM + KMS is that they really belong to Kernel Space.
So MESA do not double this code. And since those three gives some nice benefits, using something inferior is not taken into account.

*BSD must play catch up, this time, that same as they needed to catch up with HAL. But it is OK. Linux just have bigger resources allocated in desktop development.

[elanthis]

Linux just have bigger resources allocated in desktop development.

Having a smaller desktop focus than Linux must mean it has people actively working against desktop support.

[Qaridarium]

Having a smaller desktop focus than Linux must mean it has people actively working against desktop support.

or just payed by Microsoft...