AMD Is Planning To Support GLVND For Easier Linux Driver Setup & Maintenance

[computerquip]

Emil from Collabora is working on the Mesa support on behalf of Intel. He also has provided feedback along the way, so not sure what you are talking about.

There has already been patches and RFCs on the mailing list months ago.

[MaxToTheMax]

In the quote Michael published, all the AMD spokesperson said was that AMD was *interested* in GLVND. Not that they definitely will use it.

[tarceri]

There has already been patches and RFCs on the mailing list months ago.

Now that libglvnd is getting mentioned again, it appears that mesa got an RFC implementation back in September, but nobody even responded to that mail!

http://lists.freedesktop.org/archive...er/095856.html

First of all the patches were not an attempt at landing support in Mesa if you read the email:

In addition, I've put together a proof-of-concept version of Mesa that can use libglvnd. It's still a work in progress, but hopefully it will provide a more concrete example of how libglvnd works.

Second of all as I said the email was given feedback, just look in the achieves for October 2015.

[smitty3268]

First of all the patches were not an attempt at landing support in Mesa if you read the email: Second of all as I said the email was given feedback, just look in the achieves for October 2015.

But that's not the narrative they're trying to push about lazy mesa developers who ignore the brilliant work NVidia is trying to help them out with.

Stop pushing your agenda on everyone!

[computerquip]

But that's not the narrative they're trying to push about lazy mesa developers who ignore the brilliant work NVidia is trying to help them out with.

Stop pushing your agenda on everyone!

I didn't call them lazy but there's obviously a lack of interest, similar to how there's a lack of interest in supporting ARB_compatibility or a lack of interest in supporting a binary format in ARB_get_program_binary (which is BAD given how slow the compiler can be).

I tell you what. If Mesa gets a GLVND implementation before 2017, I will take every stupid word I said back.

[mike4]

I guess that's pushed now, because Vulkan can use multiple graphic cards from multiple vendors simultaneously. And I've read somewhere that Vulkan can run inside OpenGL.

[smitty3268]

I didn't call them lazy but there's obviously a lack of interest, similar to how there's a lack of interest in supporting ARB_compatibility

There's actually active hostility towards that, with some Mesa developers viewing it as terrible and not just something they lack interest in.

or a lack of interest in supporting a binary format in ARB_get_program_binary (which is BAD given how slow the compiler can be).

Somewhat fair - although it probably did make sense to focus on getting major new features like compute, tesselation, and fp64 first since they could have completely changed how the whole process worked.

Marek has been working on getting this going for radeonsi. I bet it's ready by the June release, if not the march one.

I tell you what. If Mesa gets a GLVND implementation before 2017, I will take every stupid word I said back.

bookmarking this.

[bug77]

Surely I am missing something. But why all this interest in advaced accelerated 3D graphics under Linux? I thought that 3D gaming share wasn't that big.

"Advanced accelerated 3D graphics" is not about gaming. It's about modelling and real-time simulation.
Just look at how Unigine is doing and they're pretty much ignoring gaming completely.

[anda_skoa]

Surely I am missing something. But why all this interest in advaced accelerated 3D graphics under Linux? I thought that 3D gaming share wasn't that big.

Additional to what bug77 already wrote, it is important to keep in mind that OpenGL does not equate 3D. It is a means for applications to offload parts of rendering to hardware specialized for that task.

So additional to 3D, which, as bug77 pointed out has way more use cases than just "games", this is interesting for numerous applications that need to "draw" efficiently.

One huge example would be "fluid" user interfaces (UIs using animations, etc), which are basically a requirement now for touch screen based devices, which are basically a standard now for embedded devices.
And Linux is huge in the embedded space.

Cheers,
_

[Uqbar]

Additional to what bug77 already wrote, it is important to keep in mind that OpenGL does not equate 3D. It is a means for applications to offload parts of rendering to hardware specialized for that task.

So additional to 3D, which, as bug77 pointed out has way more use cases than just "games", this is interesting for numerous applications that need to "draw" efficiently.

One huge example would be "fluid" user interfaces (UIs using animations, etc), which are basically a requirement now for touch screen based devices, which are basically a standard now for embedded devices.
And Linux is huge in the embedded space.

Cheers,
_

Thanks for clarification. Nonetheless I don't see fluid GUIs and advanced graphics as a high priority in the Linux world, especially the desktop party.
I am not saying it's useless.
Just that the current status of the Linux desktop is rather disappointing as far as fragmentation and working features.
I can read dozens of news bits talking about advanced graphics, GPUs and the likes.
But only few of them talk about advancements in the Linux desktop area.
This happens because there are more resources in the former and fewer in the latter.
It sounds to me like "to appear" is more appealing than "to be".
And this is is why I am arguing.