Nine Reasons Mesa 9.0 Is Disappointing For End-Users

Printable View

Show 40 post(s) from this thread on one page

10-10-2012, 05:16 AM
pingufunkybeat

Quote:

Originally Posted by 89c51

Michael you can complement this article with one that describes all the methods someone can help mesa. The TODOs, donations etc.

I'm just waiting for an article which will look at all of Wayland's current shortcomings.... bahahahahah, just kidding, that's not happening. Actually, I was worried because we haven't had a "Mesa is a miserable failure" article in a while.

Wait for the next article where somebody fixes indentation in Wayland (!!) then we'll have an article about the future of the Linux desktop :D "This next-generation display server brings MORE exciting changes! A header file was renamed!! Meanwhile, Mesa still doesn't support OpenGL 3.2, 3.3, 4.0, 4.1 and 4.2......... Here's a photo of beer." :)
10-10-2012, 05:48 AM
wargames

Quote:

Originally Posted by darkbasic

It isn't mesa-related but I will difinitely add:
STILL NO DECENT RADEON POWER MANAGEMENT

I agree. This is way more important than raw 3d performance. But it's not likely to come soon, because some brain-dead burocrat is afraid of their IP. Are you afraid of the Chinese AMD ? :D
10-10-2012, 05:57 AM
89c51

MESA PEOPLE CANNOT DO ANYTHING ABOUT POWER MANAGEMENT AND VIDEO ACCELERATION.

ITS UP TO NVIDIA AND AMD TO RELEASE DOCS

Hope this makes it clear
10-10-2012, 06:11 AM
YAFU

First, thank you very much to Mesa, Gallium and OpenSource drivers developers.

Quote:

Originally Posted by 89c51

Michael you can complement this article with one that describes all the methods someone can help mesa. The TODOs, donations etc.

Good point. I think the criticisms are correct as long as discuss how the project could be improved with our help. Anyway I think that Phoronix helps a lot with their benchmarks and articles, but sometimes the articles are a bit sensationalist :)

The only thing that I have to say is that I could not run "SteamPac 3d" with Mesa 8:
http://steampac3d.blogspot.com.es

Now with Mesa 9 (Nouveau driver) works as fast as with proprietary drivers.

PD:I see that write everything in capital letters and large size is allowed in this forum. It's very annoying.
10-10-2012, 06:54 AM
ChrisXY

Quote:

Originally Posted by birdie

This article seems like a part of bigger issues plaguing Linux.

It's very nice to see that Michael is not wearing rose-colored glasses.

I have only read the first two parts but I already can't take it seriously anymore.

It's supposed to be the "2012" edition, but...

1.1 PRIME/DMA-buf?
2.1 2012 edition. He/She links to SLASHDOT THREADS from 2009 and 2007. WAT
http://linuxfonts.narod.ru/files/audio.png I don't have experience about pulseaudio + multiuser but I do remember the "linux sucks" talk by datenwolf where he did a live demonstration how consolekit transferred the access rights on a fast user switch. Is the problem that the first user's pulseaudio would still have access even if it technically shouldn't have?

http://linuxfonts.narod.ru/files/linuxaudio.png No. Just no. At first sight I saw about five programs/libraries that are also available on windows. You have such a headache on windows because you can choose between directly outputting sound to the windows sound architecture or using SDL or openal? Every time someone posts this they don't seem to understand what it means: Most of the items shown are abstractions that are there to faciliate certain things or make sure you don't need to write sound system specific code.

http://linux.slashdot.org/comments.p...5&cid=39847439 No. That his sound doesn't work (yes, "doesn't work" is his whole description) out of the box with pulseaudio while alsa works is obviously a bug. But he doesn't even know that dmix has been enabled for years now? And then his ranting is incoherent that because everything was still set to pulse it uses still pulseaudio and thus sound mixing worked... So why does it suddenly work now, and how, after he purged pulseaudio? Did he not kill pulseaudio and it was still running from memory? Still, why did it work with pulseaudio now and not before? Sorry, if you rely on incoherent rants that have no reasonable description whatsoever of what the problem is you're gonna have a bad time with me.

...
10-10-2012, 09:05 AM
TAXI

Quote:

Originally Posted by 89c51

MESA PEOPLE CANNOT DO ANYTHING ABOUT POWER MANAGEMENT AND VIDEO ACCELERATION.

ITS UP TO NVIDIA AND AMD TO RELEASE DOCS

This is not 100% true. After all the radeon driver is open source, so anybody could write proper power management. See what nouveau did without any documentation? Why shouldn't the same being possible for PM (and UVD) on the radeon side? The problem is that AMD employees can't release it (AFAIK both, proper PM and UVD code has been written in-house) cause of stupid lawyers and mesa devs don't want to do it cause they fear that AMD releases their in-house work right before (or after) they have finished. IIRC at least one of the top mesa devs knows how the PM should work, but don't code it...

Some 3rd party programmer should step in right now, RE the proprietary drivers PM code, write a open source implementation and do a pull request. Yes, I know, this is unlikely to happen...
10-10-2012, 09:28 AM
ChrisXY

Quote:

Originally Posted by TAXI

mesa devs don't want to do it

... because it's the kernel driver's job, not mesa's.
10-10-2012, 02:44 PM
89c51

Quote:

Originally Posted by ChrisXY

... because it's the kernel driver's job, not mesa's.

Also dave airlie (airlied), who is the kernel graphics maintainer (read: he knows stuff about linux graphics), mentioned that they cannot do anything proper about it until AMD releases the appropriate documentation. Which is not going happen.

If someone reverse engineers it -and i thing the same goes for nvidia- then you will probably get proper dynamic PM.

The same for video acceleration.
10-10-2012, 03:11 PM
bridgman

Quote:

Originally Posted by 89c51

Also dave airlie (airlied), who is the kernel graphics maintainer (read: he knows stuff about linux graphics), mentioned that they cannot do anything proper about it until AMD releases the appropriate documentation. Which is not going happen.

Are you saying we should stop working on trying to release PM information because you know it's never going to happen ? If so, can you provide some details so we don't waste any more time ?

Does this apply to UVD as well as power management, or should we keep working on UVD ?

Thanks,
JB
10-10-2012, 03:31 PM
gens

my humble sugestion:

1. gather money(xorg foundation) for looots of cheap cards (too burn)
2. set up a (semi)automated blackbox rig or two
3. get some1 dumb enough to read hexdumps all day
4. lock him/them in a room with the rig's for a month, no proper food till its all figured out
5. ??
6. profit

Show 40 post(s) from this thread on one page