On Wed, Sep 30, 2015 at 3:53 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 30.09.2015 um 11:41 schrieb Erik Faye-Lund: >> On Mon, Sep 28, 2015 at 4:39 PM, Roland Scheidegger <srol...@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...
Nowadays, a lot of applications use several contexts and threads such as web browsers (firefox, chrome) and game engines (UE4). Historically, web browsers suffered most from the sampler-view <-> context dependency and we had some ugly bugs due to that. (making sampler views per-screen would simplify that code a lot) The number of multithreaded GL applications is only going to grow and drivers must already be thread-safe to be considered usable. Also, piglit has a multithreaded shader-compiling glx test that has been very useful for fixing race conditions in our driver. We definitely need more of those. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
