Luc Modularizes Mesa, DRI Drivers

[libv]

SDK capable mesa tree now available!

at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

I am still working on a README, and will make more noise once i have had some shut-eye.

For the adventurous, here is the quick summary:
* pick versions that are very close to your current mesa version (libGL needs to match)
> ./autogen.sh [maybe want to add --prefix=/usr/]
> make dri-sdk
> make dri-sdk-install

Then you can build, install and run your dri driver.

[libv]

Luc,

For X server 1.9, the tentative plan is to merge the device-dependent drivers back into the X server.

Your work here on Mesa seems to be doing the opposite.

So, do you disagree with the move to merge the DDXs into the X server? If so, please explain.

If not, how is the situation with DDX/X server sufficiently different from Mesa to warrant this move in the opposite direction?

Moving drivers back into the X server is the single worst thing that people can do at this point.

Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.

[mattst88]

Luc,

For X server 1.9, the tentative plan is to merge the device-dependent drivers back into the X server.

Your work here on Mesa seems to be doing the opposite.

So, do you disagree with the move to merge the DDXs into the X server? If so, please explain.

If not, how is the situation with DDX/X server sufficiently different from Mesa to warrant this move in the opposite direction?

[miles]

Ok

Well, this is one of those touchy subjects were i go on the defensive immediately, so sorry for not capturing what in other cases would've been a good laugh for me

That's ok, being an outsider anyway I do appreciate each and every one's work on Xorg, and I'm really happy to see developers like you working on improving the code

[libv]

First; this is a very nice example where open source software is just awesome! Don't loke something change it.. sadly that is only true if you're a skilled programmer.

@luc (libv)
Why don't you simply fork xorg till they allow your structure to be THE structure to write drivers? You seem like someone that has the knowledge and will to do so and that will "fix" your issue of keeping your code working on xorg.. (if you fork, please enable ctrl+alt+bcksp by default again )

Anyhow, awsesome job however it turns out.

Well, forking is not my style and something like that does not succeed on its own, especially not for technical reasons. Forks are mostly only about politics and people trying to protect or enlarge their power-base outside of technical advancement.

About not liking something, and/or not liking the general direction of things, and then coding up how they should be... I have done that many times before. And several of those have turned out to be real winners, even though the people who get proven wrong in such a case, are usually not very sportive about it. This means that credit is then not given where credit is due, and this is where the whole meritocracy thing breaks down, as the next time round, the same story has to be played all over again, in pretty much the same way, with a sizable waste of resources as a consequence.

About ctrl-alt-bcksp... I miss that too (i know, it's only off per default). It's like the X stipple and the VGA text console. When you see the stipple, you know that your driver code is not horribly broken. When it is horribly broken, you might still have ctrl-alt-backspace, which then hopefully gives you the VGA console again. If you see the VGA console again, you get to play again... All 3 are happily tied together for a graphics driver developer

[libv]

?

I fail to understand. Did you mistake me with duby229? Or should I have prefaced my post with "CAUTION: IRONY" ?

Ok

Well, this is one of those touchy subjects were i go on the defensive immediately, so sorry for not capturing what in other cases would've been a good laugh for me

[miles]

So you think that my efforts to straighten out the X.org foundation are not very productive?

?

I fail to understand. Did you mistake me with duby229? Or should I have prefaced my post with "CAUTION: IRONY" ?

[markg85]

First; this is a very nice example where open source software is just awesome! Don't loke something change it.. sadly that is only true if you're a skilled programmer.

@luc (libv)
Why don't you simply fork xorg till they allow your structure to be THE structure to write drivers? You seem like someone that has the knowledge and will to do so and that will "fix" your issue of keeping your code working on xorg.. (if you fork, please enable ctrl+alt+bcksp by default again )

Anyhow, awsesome job however it turns out.

[libv]

from the FOSDEM videos Michael posted here it seemed like Intel guys were not convinced this will work

I'm interested to see how this will turn out, if indeed will improve things or not.

where/how will we hear about the results? (I'm no kernel/video coder so I can't just grok through code)

Oh, it works, it simply works I have tested in on 7.0, 7.2, 7.4, 7.6 and 7.7 for radeon (r200, r500), unichrome and swrast.

And as said before, the Makefile work needed to build the libraries and the SDK will hopefully get finalised tonight, so everyone can go and verify that this really does work.

But as long as this is not accepted as the way forward, it will be a pain keeping the SDK and the separate drivers up to date. But it is not impossible, just a bit of a hassle.

[karl]

from the FOSDEM videos Michael posted here it seemed like Intel guys were not convinced this will work

I'm interested to see how this will turn out, if indeed will improve things or not.

where/how will we hear about the results? (I'm no kernel/video coder so I can't just grok through code)