[Mesa-dev] Question: st/mesa and context-shareable shaders

[Roland Scheidegger]

Am 30.09.2015 um 11:41 schrieb Erik Faye-Lund:
> On Mon, Sep 28, 2015 at 4:39 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>
>> In short, for simplicity, only things were sharable which were really
>> required to be shared (pretty much just actual resources - and yes that
>> doesn't work too well for GL neither as you can't share sampler/rt
>> views, let's face it GL's resource model there from legacy GL is a
>> disaster, not that d3d9 was any better).
> 
> OpenGL allows sharing the objects that potentially take up a lot of
> sharable memory, like shaders, programs, texture images, renderbuffers
> and vertex buffer objects. But not those who does not, like
> framebuffer objects and sampler objects. This makes a ton of sense to
> me, and calling this model "a disaster" seems quite unfair.
The "disaster" was in reference to the separate textures/renderbuffers,
which imho really is a disaster - of course this has its root in actual
implementations (which sometimes even had separate memory for those). It
continues to make problems everywhere, there's still some ugly hacks for
instance in the mesa statetracker which we can't get rid of (because
some optimal format for a texture might then not be renderable). So yes,
"resources" need to be shareable (albeit GL calls them vbos, textures,
renderbuffers). And yes these can take up a lot of memory.
Typically, shaders/programs were much smaller than these, albeit they've
grown considerably - don't forget gallium is more than 7 years old too.
So maybe that they are sharable in GL was a reasonable forward looking
choice, but gallium was meant to make things easier for drivers, and
typically there was no way you could compile things to hw without
context information in any case.

> 
>> And IIRC multithreaded GL in general never really used to work all that
>> well and noone was really using that much.
> 
> That's not quite true. I've been writing multithreaded OpenGL
> applications professionally for the last 7 years, and I've experienced
> very few problems with the proprietary drivers in this respect. OpenGL
> multi-threading works fine, and is in rather heavy use out there. You
> might not see those applications, but they exist. And they have been
> existing for a long time, without notable problems.
> 
There were some minimal demos in mesa for multithreaded GL, and IIRC
they didn't make problems only in mesa itself. Though granted maybe 7
years isn't back far enough... I thought though the usefulness was
typically quite limited but it wouldn't be surprising if that changed
too (so if you actually compiled your shader in a different thread, I
wouldn't have been surprised if most of the compile time was actually
spent in the thread where you first used that shader anyway). Of course
10 years back most people didn't even have dual-core cpus...

Roland