If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Yes. They are too late. But they are here and they work fantastically up to r500 hardware.
I don't know if you ever owned an r300-500 hardware but, its the main reason linux is not mainstream. You have the patience to wait for features whilst most people out there don't. You are off the topic I'm not. And don't call people troll if they're not deceived by amd.
It WOULD, however, be interesting to know if AMD is planning to invest more manpower into Mesa/OpenGL3 now that they have pretty much caught up with the latest generations.
It seems like it is relatively fast now (still difficult, of course!) to bring new generations up to the current level (OpenGL 2.1, powersaving, EXA, all that sweetness), but there it gets stuck waiting for general Mesa to progress, which is mostly unpaid volunteer work.
For full support of the r600+ hardware, this Mesa bottleneck will have to be tackled, and it won't be Intel, who don't produce OpenGL3 hardware.
I don't know if you ever owned an r300-500 hardware but, its the main reason linux is not mainstream. You have the patience to wait for features whilst most people out there don't. You are off the topic I'm not. And don't call people troll if they're not deceived by amd.
The whole waiting was caused by a huge backlog caused by neglecting OSS drivers for many years.
The gap has been closing very rapidly. We waited years for basic r600 support, which is not acceptable. The HD6000 support came in a couple of months, and Fusion even befor launch, which is already decent.
So it went from a serious problem to a minor annoyance, if even that. I don't think that THIS is the problem of the Linux desktop, as much as companies who simply do not feel like porting due to a small market share, and a userbase which strongly prefers open alternatives in the first place.
The Android port is currently targeting NVIDIA TEGRA 2 platforms. In doing this port, the Unigine Engine has picked up support for a Java-based launcher, multi-touch screens, and OpenGL ES 2.0.
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
What does Presentation Mode have to do with the subject at hand?
He did not have a projector or a second monitor, he just wanted a virtual screen.
Anyway i find the problem pretty relevant as the X server should not stop on such an error.
Some ways to handle that ( from best to worst ):
1. ignore that config line, report error and continue ( no virtual screen but usable system )
2. pause in text mode and ask the user if they want to review the faulty config and fix it
3. just drop the user to a VT
Anyway i find the problem pretty relevant as the X server should not stop on such an error.
Some ways to handle that ( from best to worst ):
1. ignore that config line, report error and continue ( no virtual screen but usable system )
2. pause in text mode and ask the user if they want to review the faulty config and fix it
3. just drop the user to a VT
If Linux ever wants to be a serious competitor on the desktop market then option 1 is the only way to handle it.
Shortage of open-source driver development manpower is a problem. So is the "you don't want documentation" attitude among vendors. They're related, but different, problems. Acknowledging one does not invalidate the other, and a solution to one does not solve the other.
But designing a groundbreaking GPU or writing OpenGL drivers that don't suck are a shitload of hard work to do. So why share this technology?
Because designing the hardware and writing the driver is what the customer paid for and being stuck with blob that can break at any time is not an option.
See, while companies like AMD and Intel fund a lot of OSS development (Kernel, Mesa, X, and others), Nvidia has never helped OSS in any significant way.
We're pretty much on the same page but I believe that even catering to people who just want stuff to work immediately to it's full potential and don't care at all about how it's done can still be of much more use to us in the long run than you seem to think. At least when such a crap is not trying to make it inside the mainline kernel.
I won't support such a company, even if Unigine heaven looks groovy. I jumped off that ship years ago after my hardware got deprecated, did not work well with KDE4, and there was no open source driver to fall back on. The automatic update of the drivers simply left me with a dead X and left me debugging.
Me neither, but people usually have to learn the hard way.
After all that's what I paid for when I bought my graphics card: the hardware and the driver.
I do agree with this for the most part.
When I got my ATi card, I paid for the hardware, the OPEN SOURCE driver for my open source OS, and for the specs so I can use the hardware if I need to.
ATi and Intel offer that, and they will be the vendors I consider in the future. Companies who demand that I inject 30 MBs of unknown code into my kernel before my card works will not have my support.
Nvidia (and ATi) binary drivers avoid this by simply writing all this in closed source, giving you a replacement operating system.
What Intel and AMD are doing now is supporting the Open Source work to improve this. This is good, and it comes quite late, so there is lots of catching up to do.
What Nvidia is doing is jackshit.
If you buy from AMD or Intel, you directly support Linux. If you buy from Nvidia, you are effectively sabotaging it and replacing it with a half-closed system.
? and that's why. If anyone wants something that "just works" then he should go grab nVidia GPU and use it with their blob, but he should at least consider that he's not exactly helping to solve the problem because he's obviously OK with something that can start rapidly deteriorating at any time with no one able or willing to fix it.
Do they support OpenGL 3.3/4.1? Do they support OpenGL ES and WebGL stuff? Do they accelerate HD video? Don't they suck like fglrx does? Just give me the name of your planet and I'll find speak with you face to face
OpenGL 3.3/4.1: Not yet.
OpenGL ES: I suppose that's pretty much on the same level as regular OpenGL, but relatively new and probably not so well tested.
WebGL: All demos from the repository are working.
Universal hardware video decoding is a work in progress.
Here comes my favorite part: there's just no way in hell R600g sucks as much as fglrx in any aspect I care about. But I guess I'm quite patient and not so hard to please.
And how many users could have become linux users if they didn't drop support leaving people with half-baked drivers?
I have to admit that it took me quite some time to realize that what really matters is not bringing as many people aboard as possible as quickly as possible, but rather helping to make sure that GNU/Linux survives that without becoming yet another OS not worth using.
Ask questions, be skeptical and you'll realize the answer. For sure you'll recognize the truth when amd will drop support for r600-r700 hardware and when people won't be able to play modern games with good performance and stability or digest webGL content with their hardware without bugs, but it will be a bitter moment.
The question I'm always asking myself when "voting with my wallet" is "how can my hardware stay supported as long as I need it to?" and an answer for that question is "definitely not with blobs."
I can see why trying to design and maintain stable interfaces for blobs is not an option in any OS that doesn't wanna run into serious trouble in the future and I think that kernel developers are being very reasonable when they refuse to even consider letting anyone force them into making lots of short-sighted decisions they could regret for the rest of their lives just because some blob might break.
I can understand that not everyone has the patience for waiting as long as it takes to make things right in the open, but I have lightning fast (compared to fglrx) GUI and satisfactory OpenGL support (enough to play native games and use WebGL in Chromium) provided by robust and secure libre driver (R600g) right now. It's obviously not perfect yet but it's reliable enough for me to be able to depend on it which is all that really matters, at least as far as I'm concerned.
I agree that the current status quo is far from ideal but I'm OK with it especially considering where things seem to be heading and that libre drivers seem to lack the concept of throwing people overboard prematurely, which is something you obviously can't say about blobs.
Because designing the hardware and writing the driver is what the customer paid for and being stuck with blob that can break at any time is not an option.
What about a blob that doesn't break and actually works? Like we have on Windows, for example.
Comment