On Wed, Feb 17, 2016 at 10:04 AM, Jose Fonseca <[email protected]> wrote: > On 17/02/16 10:24, Dave Airlie wrote: >> >> On 17 February 2016 at 18:31, Ernst Sjöstrand <[email protected]> wrote: >>> >>> Hi! >>> >>> Sorry if this is a silly question but I was thinking that there would >>> be a Vulkan Gallium state tracker in development behind closed doors >>> somehow. However I guess that's not the case? >> >> >> It doesn't make sense to write a vulkan state tracker for gallium, as >> vulkan is a lower level interface >> than gallium, >> >> The only thing that makes sense is to refactor pieces of the gallium >> drivers out into some shared >> driver code, usually the compiler and memory layout stuff (like Intel >> have done). >> >> You could in theory write a vulkan level gallium layer, but it really >> would end up looking like >> vulkan so would just be an abstraction of an abstraction. >> >> Dave. > > > I still need to catch up reading the final version of the Vulkan specs. > > But wouldn't it be useful to have abstraction that is a superset of Vulkan? > > > That is a Vulkan-like API that exposes additional state that was in OpenGL > but was removed from Vulkan API, and that the existings GPU HW supports, and > makes live it easier to implement OpenGL. > > Just for the sake of this explanation I'm going to call this new abstraction > Germanium (just so there's a name, but it really doesn't matter).
heh, I was going to call it "vallium" :-P > > We'd have three ways of assembling things: > > - a Vulkan driver > > > Vulkan Germanium > API interface > ---------> Trivial glue ----------> shared driver > > > - a classic Mesa driver > > OpenGL > API > ---------> Mesa -> Germanium ------> shared driver > statetracker One use-case I do care about, and I think would be easier with this sort of approach, is supporting multiple generations of gpu which have a lot of shared code. The internal germanium/vallium layer wouldn't have to support all the features of vulkan to still get opengl state tracker support on older gen's.. I guess that is the one advantage compared to mesa-internal extensions exposed thru vulkan.. BR, -R > - and maybe for a transitory period a Gallium->Germananium adapter > > OpenGL/D3D > ------> existing statetrackers --> Germanium gallium driver --> shared > driver > > > But eventually Gallium would just disappear and the difference between > classic/Gallium driver would go away. New drivers would be coded against > the Vulkan-like Germanium interface, and target both GL/Vulkan > simulatnously. > > > We could fix an IR for Germanium (e.g, SPIR-V, or NIR), or instead let > Germanium IR be switchable (eg, allow TGSI, LLVM), and let drivers plug > compilers as needed. > > > > Of course, people could just try to implement a Mesa -> Vulkan adapter. And > when writing new drivers people would just write a Vulkan driver. But there > are probably lots of technical challenges in implementing full OpenGL (or > D3D) on top of pure Vulkan. > > > Another solution would be to expose the > bits-useful-for-GL/D3D-but-missing-in-Vulkan as "Mesa-internal" Vulkan > extensions. > > Jose > > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
