Mesa Slowly Picking Up OpenGL 3 Support

[nhaehnle]

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.

I've decided not to do OpenGL 2.0 in classic Mesa. If somebody else wants to do it I'm not going to stop them, but personally I believe it would be better to let classic Mesa mature at OpenGL 1.5.

Of course, my biggest contribution to OpenGL 2.0 support will probably be in the shader compiler, which is shared between the drivers.

[nhaehnle]

To clear up a lot of misunderstandings here in the thread...

First, OpenGL 3.0 is a problematic beast due to the different profiles. Any driver supporting OpenGL 3.0 must actually support all the legacy features as well, and it would therefore be insane not to base them on Mesa. Therefore:

Intel reinventing the wheel as always. Gallium3D is a must, please not poison it...

Since Ian's work contains the core Mesa support, which is in turn used by the Mesa/OpenGL state tracker, this is definitely *not* wasted work.

For OpenGL 3.2 core mode, it would be cleaner and more efficient (from a run-time performance point of view; from a development point of view it would be very inefficient) to have an entirely fresh restart and a non-Mesa based state tracker.

Unfortunately, such a state tracker would obviously not be able to support legacy features; not a big problem if applications weren't expecting those features, but I'm afraid NVidia will set (or has already set) a precedent even on Linux in supporting OpenGL 3.2 with the full backwards compatibility, so applications will expect this full compatibility and so our drivers will have to support it and so we will be back where we started: at a 3.x capable state tracker based on Mesa; and therefore, Mesa needs those extensions.

Developing 3.x state trackers in Mesa seems like a tremendous duplication of effort, considering Gallium already has them.

Uhh... no? Where did you get that idea?

[ioannis]

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

[ioannis]

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.

[Ant P.]

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

Has their driver caught up to Intel's OpenGL 2 support yet?

[nanonyme]

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.

[BlackStar]

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.

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

[airlied]

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.

Dave.

[BlackStar]

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.

[ioannis]

catch 22

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