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.

AMD should take notes from Intel. Proprietary drivers don't make sense.

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 phoronix

AMD (is) mostly focused on their proprietary graphics drivers

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)?

How about assembling a GLSL team?

Hey Intel,

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.

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.

Hmm ...

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...

Unless you mean Nvidia that statement makes absolutely no sense. It's not exactly like AMD can just stop making the proprietary driver and throw it's weight completely behind the open source driver, they still need to provide the proprietary driver for the time being for both Windows and for the Workstation users for whom they're actually doing the proprietary drivers on linux for, meanwhile they've been working on bringing up an opensource driver stack which until recently wasn't really capable of replacing the proprietary drivers for most users due to lacking proper dynamic power management and the 3D performance being poor and even today none of the drivers are compatible with the latest openGL spec, and openCL last I heard was still a WIP. As a result of all of that they still really can't switch their workstation market over to using the opensource drivers and even then unless they switch over their windows driver to being based on the opensource ones it's not like they can exactly throw most of their effort behind it. Whatever happens though my guess would be they're a few years away from being capable of switching and even then it's a question as to whether they will or not.

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.

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.

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...

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.

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.

My statement was more general, there's no reason to keep drivers proprietary. They are hardware specific anyway, and the hardware is proprietary.

Of course their Windows driver must remain proprietary.

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.