Luc Calls For A Dead Linux Desktop If Keith Gets His Way

[nanonyme]

Yes and no... you still need a DDX because *something* has to accept modesetting and 2D/Xv acceleration requests from the X server, the question is to what extent a generic DDX is feasible -- which in turn implies something like Gallium3D for acceleration and a consistent-across-hardware-vendors modesetting interface.

AFAIK the current thinking is that memory management (mostly in the kernel, but with a non-trivial userspace component in libdrm-<hw>) is hardware-vendor-specific, and as a result the idea of a generic DDX doesn't seem as likely in practice as it did in theory.

Surely if that's true, merging ddx's into a generic component in X server wouldn't help at all either but would also be a good theoretical solution bad in practice? There can't really be two opposite truths about the generic driver, you know.

[tmpdir]

Difficult choice, won't be an easy sell to other the other x devs...

will be fun to read about it (in stead of being in middle of it for once)

[ua=42]

It's not a small one. It's a big one. You're forced to pull all driver updates, not only those you want. And if one of the updates is not suitable for you, tough. And you have to wait too long to update in the first place, regardless of the individual readyness state of each driver.

Massive driver updates all at the same time is simply brain damage.

I know. I had the horrible decision whether to upgrade the 100mb kernel to a newer version for the wireless to work, but the new version had a bug with load balancing that killed battery life. So instead of a 1-2Mb update in windows... I have a 100MB file that has a bug regarding cpu. I ended up downloading an older kernel (another 100MB!!!) to get both to work.

[luap]

Mesa is a problem

In all of this, I keep coming back to the question of Mesa. Why are there "Mesa drivers" for different hardware? Mesa claims to be a software implementation of OpenGL. As such, there should be no drivers tied into it. One should create a GL driver, and where the hardware does not support a feature you can add a dependancy on Mesa to handle it in software (very slowly). It seems that instead things are flipped around and Mesa is the center of the universe and it has drivers to *help it* where possible. IMHO if you have hardware that supports some GL version, you should be able to implement a driver that supports that with no Mesa dependency at all. Or is this what Gallium is attempting to do?

Then there's Wayland. How is that supposed to work if the drivers go back into X? I look forward to an X-free option for the desktop.

Keep it modular and work on getting hardware specific code out of Mesa.

-my 2 cents.

[personman]

*rant* *rant* Can somebody of phonorix please change the title from 'Luc Calls For' to 'Luc Warns For'. Please don't put up such nonsense titles again phonorix.

Thats what I said!

http://www.phoronix.com/forums/showpost.php?p=148258&postcount=7

Where exactly is the "call for a dead linux desktop?"

A developer theorizes that moving the drivers in to the server will kill the linux desktop... He doesn't "call for it."

I theorize that a volcano will erupt... Does this mean I advocate volcanoes?

"Luc is very much in starch opposition..."

Potatoe fight?

Ridiculous... Before there was the "disaster" of an RC1 KERNEL with a performance degredation.

You know... we have a fairly high-brow, technicly proficient audience here.

BS and sensationalism is unneccasary. IIRC, I've seen threads on other sites using Phoronix as a joke/insult because of these over-sensationalized headlines.

-Andy

[nanonyme]

In all of this, I keep coming back to the question of Mesa. Why are there "Mesa drivers" for different hardware? Mesa claims to be a software implementation of OpenGL.

*cough* Similar to OpenGL.

[pingufunkybeat]

In all of this, I keep coming back to the question of Mesa. Why are there "Mesa drivers" for different hardware? Mesa claims to be a software implementation of OpenGL. As such, there should be no drivers tied into it. One should create a GL driver, and where the hardware does not support a feature you can add a dependancy on Mesa to handle it in software (very slowly). It seems that instead things are flipped around and Mesa is the center of the universe and it has drivers to *help it* where possible. IMHO if you have hardware that supports some GL version, you should be able to implement a driver that supports that with no Mesa dependency at all. Or is this what Gallium is attempting to do?

Each driver which accelerates OpenGL must have an implementation of the OpenGL API, which is a huge amount of work. Mesa is such an implementation, and adding a different codepath to already existing functions is easier than rewriting OpenGL from scratch.

Keep it modular and work on getting hardware specific code out of Mesa.

This is roughly what the Galium3d infrastructure brings.

[bridgman]

In all of this, I keep coming back to the question of Mesa. Why are there "Mesa drivers" for different hardware? Mesa claims to be a software implementation of OpenGL. As such, there should be no drivers tied into it.

I think the real problem here is a slightly old web page. When Mesa was initially implemented and documented (16 years ago) it *was* a software implementation of "a graphics language similar to OpenGL". Hardware driver support was added later -- back when GPU hardware was *designed* around the OpenGL pipeline -- and the classic mesa HW driver interface reflects the fact that it was designed around "OpenGL-influenced hardware".

GPU internals have become much more programmable over the last 10 years, and the Gallium3D HW driver interface was proposed as a more modern replacement - designed around common GPU features rather than around OpenGL features. The Gallium3D HW drivers have been moved out of the mesa tree (although not the mesa *project*) so I think all the things you want are happening.

**

OpenGL driver is in /mesa/mesa project, src/mesa folder

Classic HW drivers were in mesa/mesa project, src/mesa/drivers/dri folder (inside mesa)

Gallium3D drivers are in mesa/mesa project, src/gallium folder (outside mesa)

[allquixotic]

+1 for mostly maintaining the status quo.

Extra-extra-modularizing stuff even more than today would be bad for performance (all that dynamic linking and vtable lookups and runtime checking and void* APIs). Demodularizing stuff back to pre-modular X days would be bad for maintainability, and reintroduce the distribution headaches that made the stack so broken back then.

So I think the model that has been working well for Xserver 1.6, 1.7, 1.8, 1.9 should continue. Trying to change it either for more modularization or less is going to slow down progress on all the current driver work, create unnecessary churn, and cause problems in the long run. Leave well enough alone. God, software engineers are the worst example of people fixing things that aren't broken.

[squirrl]

http://www.mail-archive.com/[email protected]/msg42660.html

Last year they called me a troll.
see above.