They do make sense for AMD, since they don't have enough development resources to have full open-source support on new GPU generation launches.
Originally Posted by xeekei
Really? It seems like they make minimal effort to get their Windows driver working on Linux and most of the Linux development resources go to open-source. Is bridgman around to give a head count (probably has before for)?
Originally Posted by phoronix
How about assembling a GLSL team?
I know I'm only on the outside looking in, but it appears that of all the features, GLSL is either the hardest to implement, or takes the most time for piglit/etc verifications, the most in-depth; I don't know what would be the proper way to describe how it looks from out here.
But It seems like GLSL 3.2 and 3.3 have been "in progress" fffffoooooorrrrreeeevvvveeeerrr, so why not keep whomever is the core development team for MESA GLSL on GLSL - when they get done with 3.2 and 3.3, in light of the Fred Brooks problem, put them right on GLSL 4.0.
When the GLSL team is done with GLSL 4.0, put them on GLSL 4.1.(Skipping the rest of the OpenGL features)
When done, put them on GLSL 4.2.
When done, put them on GLSL 4.3.
Then GLSL 4.4.
Then GLSL 4.5. (Yes, I know it doesn't exist yet. But it probably will by the time all these other GLSLs are done)
Just a random thought from a complete outsider looking in. A dedicated GLSL Mesa team seems to make a lot of sense. The rest of the features will catch up.
Ehh, GLSL features are pretty much done through 4.2 already, with the shader pack 420 extension already present in Mesa 9.2. The current holdup on 3.2 isn't the GLSL part, it's implementing all the piglit tests for geometry shaders and the i965 backend. Same is going to be true of 4.0 in a few months - it won't be the GLSL support holding it back, but core/driver functionality like fp64 support. Adding that to GLSL will be easy.
Originally Posted by halfmanhalfamazing
They may have grown a lot, yet they still seem to ignore almost all bug-reports filed at freedeskop's bugzilla, whereas a bug filed against the intel-ddx is usually fixed in a day or two by Intel's SNA hacker chris wilson...
Only having a single open source driver do make more sense. Of course as things are right now they can't just drop the proprietary one over night. My statement was more general, there's no reason to keep drivers proprietary. They are hardware specific anyway, and the hardware is proprietary.
Originally Posted by Luke_Wolf
And it's not like they put much effort into their proprietary Linux driver anyway.
Well, AMD's open source team has grown from one guy to five in the last five years, isn't it? Meaning it has been x5.
So if you consider the size of open source teams compared to the size of the company, I would say AMD's Linux effort is actually bigger than Intel's.
On the whole, however, these comparisons make little sense, I guess. Congratulations to both companies for developing mesa.
I can confirm your impression. For me, the important patches to get Steam/SourceEngine games running on Gen4 graphics came from a non-Intel programmer called Chris Forbes.
Originally Posted by Linuxhippy
I don't know which features are used more often, but i just prefer when games run without override and reasonable fast. Source engine games are not the fastest but could compete with lowend nvidia cards, Killing Floor has no rendering errors (but maybe ask the D3D team to resolve some speed issues), Serious Sam 3 needs attention, i did only test mesa 9.1.x but will test again 9.2 when is released. Hopefully no override value is required - even with that set it was basically slow as hell. I mainly test Ivy Bridge as i don't have got Haswell. It is at least nice that Intel wants feedback which issues should be fixed first, lets see if i could play my favorite Linux games without switching gfx cards all the time KF i mainly play with AMD cards (a bit faster than Intel, no rendering errors), Source engine (L4D2) runs best with Nvidia. For SS3 all OpenGL implementations are slow. But thats a general problem, even the OpenGL stack on Win is slower than D3D - but Intel Linux is definitely the worst.
Of course their Windows driver must remain proprietary.
Originally Posted by xeekei
The proprietary Linux driver is simply a port of that.
AMD will not start using Mesa as their driver on Windows, so Catalyst is here to stay. And on Linux it supports OpenCL, OpenGL 4, and a bunch of other things which are important for their paying customers.
I want to see FLOSS drivers develop, and I am very happy about recent changes and progress, but I do understand why Catalyst is still there.
@Chol: I should point out that I do contract to Intel now -- so not quite the free agent I might appear to be