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.

Mesa Slowly Picking Up OpenGL 3 Support

08-31-2009, 07:20 PM

Phoronix: Mesa Slowly Picking Up OpenGL 3 Support

Intel's Ian Romanick has announced on the Mesa3D development list that he has made available an arb_sync branch of Mesa. As implied by its name, this branch implements support for the GL_ARB_sync extension, which just officially debuted with OpenGL 3.2...

Comment

for drivers to pick up Gallium3D it needs to be mature, for Gallium3D to mature it needs to be used...

I doubt Intel is having doubts about its maturity. It's more likely that they don't want to spend the resources bringing their OpenGL drivers up to date. Note that Intel has refused to implement OpenGL 3.0 in their current-gen GPUs, even if they *do* support the necessary features. Their comment on the OpenGL 3.x release is enlightening:

"Intel is excited about OpenGL 3.1, the continuing evolution of OpenGL, and our future product support of OpenGL 3.x"

which translates into "we won't be supporting OpenGL 3.x in the foreseeable future", if you cut the marketing bullshit.

I hope I will be proved wrong, but Intel will not be supporting Gallium3d any time soon.

Comment

I doubt Intel is having doubts about its maturity. It's more likely that they don't want to spend the resources bringing their OpenGL drivers up to date. Note that Intel has refused to implement OpenGL 3.0 in their current-gen GPUs, even if they *do* support the necessary features. Their comment on the OpenGL 3.x release is enlightening:

"Intel is excited about OpenGL 3.1, the continuing evolution of OpenGL, and our future product support of OpenGL 3.x"

which translates into "we won't be supporting OpenGL 3.x in the foreseeable future", if you cut the marketing bullshit.

I hope I will be proved wrong, but Intel will not be supporting Gallium3d any time soon.

I suspect you are confusing Intel and Intel :-)

Intel Linux drivers will most likely support GL3.0 via Mesa, I suspect the comments you read referenced windows drivers.

Intel don't want to face the gallium3d regression cliff, when they moved their driver to the buffer manager the regressions took a long
time to fix, moving again to another re-write is just going to cause similiar issues.

Really a community gallium driver would need to be developed that would show Intel a reason to switch or use gallium for other bits of the stack
like video or X.org driver or OpenCL.

Comment

Intel Linux drivers will most likely support GL3.0 via Mesa, I suspect the comments you read referenced windows drivers.

Good one. :-)

The comment was Intel's official statement on the release of OpenGL 3.0 and 3.1 (they made the same statement word for word) - you can find it on the official release statements on opengl.org. As far as I can tell, Intel has separate driver teams for its Windows and Linux drivers (which indicates a certain amount of schizophrenia), but is the Linux driver team so independent that it can disregard the official policy of the company?

I honestly have no idea.

Really a community gallium driver would need to be developed that would show Intel a reason to switch or use gallium for other bits of the stack like video or X.org driver or OpenCL.

Sigh. Yes, what the user really needs is yet another fork of driver code. Why not keep supporting current drivers with bugfixes but start developing a Gallium driver in parallel, just like AMD does? Developing 3.x state trackers in Mesa seems like a tremendous duplication of effort, considering Gallium already has them.

Not to mention that Mesa developers have stated time and time again that classic Mesa is not a good fit for modern hardware and OpenGL features.

As things stand, AMD has become the only company that actually supports state-of-the-art OSS Linux graphics...

Comment

Yes, what the user really needs is yet another fork of driver code. Why not keep supporting current drivers with bugfixes but start developing a Gallium driver in parallel, just like AMD does?

Actually they're not. r300 Gallium driver is being developed by a few volunteers on their spare time. (and it has developed pretty damn fast considering that)
I also seem to notice that there might've been some design mistakes (or maybe just plain simple idealism) while doing Gallium3D that have been fixed later on, like that now it seems the same compiler used in classic Mesa can be used in Gallium3D too which saves time porting the drivers. I haven't yet heard comments from radeon developers that anyone would actually want to do a full implementation of even OpenGL 2.0 with classic Mesa so I'd assume sooner or later at least radseon drivers migrate to Gallium3D API and that would be the community Gallium driver airlied spoke of, me thinks.

Comment

I hope I will be proved wrong, but Intel will not be supporting Gallium3d any time soon.

actually, probably the first GPU Gallium3D driver was that for the i915 IGP (the other one being for the Cell SPUs), followed by i965, Nouveu project and later AMD, which I think is described as being in a 'good' state. That makes it ever more strange that they are trying now to 'force' OpenGL 3.x features down Mesa's throat.

Comment

the following is my personal view on Gallium3D's state. If you are closely involved in the development of Gallium, please correct me if I'm wrong.

The state-trackers API is in a good enough state, hence why we see them being developed fairly quickly. However, the driver side is less evolved, with rough edges and yet to be defined clean APIs. For instance, there are some platform dependent parts that mix with what should have been platform independent code (see winsys). Even the IR is in flux, with efforts to switch to LLVM from Tungsten's in-house one. Because of that, people are reluctant to commit to Gallium3D at this state and any drivers developed thus far are more like testbenches, to see what is missing and what direction things should take.

This is not to say that it's a bad approach. Gallium3D requires a generic enough API that can meet the needs of different platforms and thus requires time to find a good balance. But it's not wine that you leave it standing in a cellar (AKA repository :-P) to mature