Where is vulkan!?

[timofonic]

If they don't change the strategy, Romulans will win...

They ought to make the United Confederation of Interstellar Planets.

[bridgman]

Granted, I'm not an expert in any of this, but looking at the "API" (ie. the parts Gallium would expose were it a public rendering interface and not just a cog inside mesa), it still looks like a lower level OpenGL state machine; you can set all sorts of "registers" (blend/stencil/scissor etc.), bind shaders individually, and most importantly, issue immediate mode draws. There is no concept of explicitly building command buffers for delayed submission whatsoever, and no concept of compiling state into bigger reusable objects (ie. PSOs. btw. isn't this a D3D12 term?).

Yep, but to my little mind that says Vulkan is arguably higher level than Gallium3D in some ways, not lower level. In terms of state management Gallium3D is lower level, but in terms of command submission it's just "different" -- lower level in the sense that multiple draw commands are batched and submitted by the Gallium3D drivers, higher level in the sense that you can't prepare a command buffer separately from submitting it.

I don't know how hard it would be to meld Gallium into that kind of model, but to someone who knows how complex changes in heavily intertwined codebases can get, it feels like a monumental task. Also, AFAIK Gallium has drivers for a couple older hardware that certainly don't map to the Vulkan/GCN model. I really don't know what you'd want to do for those.

Yeah, it would take some design work but IIRC there are relatively few places in the stack that touch the top level of Gallium3D today so (a) wiring in a "Gallium3D 2.0" wouldn't have to hit much code and (b) if we had to add a switch so that newer HW generations used the newer interface and older HW generations stayed with existing Gallium3D pipe drivers it probably wouldn't be too bad. AFAIK there's basically one place in Mesa that calls into the top of Gallium3D pipe drivers, then a lot of different drivers that implement the pipe interface.

[Ancurio]

Depends on whether that's actually the case or not. I have heard confident statements made both ways.

Given that Mantle, Vulkan and Gallium3D were all intended to expose the hardware's command submission and memory mapping capabilities directly, I wouldn't expect a big difference in abstraction level. Haven't had time to go through the Vulkan spec in detail (it's surprisingly big) but from a quick read I didn't see anything contradicting that yet.

It's going to depend on whether Gallium3D or the libdrm interface ends up closer to the Vulkan API. At first glance there are a lot of common elements between the Gallium3D and Vulkan interfaces, particularly the use of constant state objects (PSO's in Vulkan).

Granted, I'm not an expert in any of this, but looking at the "API" (ie. the parts Gallium would expose were it a public rendering interface and not just a cog inside mesa), it still looks like a lower level OpenGL state machine; you can set all sorts of "registers" (blend/stencil/scissor etc.), bind shaders individually, and most importantly, issue immediate mode draws. There is no concept of explicitly building command buffers for delayed submission whatsoever, and no concept of compiling state into bigger reusable objects (ie. PSOs. btw. isn't this a D3D12 term?). I don't know how hard it would be to meld Gallium into that kind of model, but to someone who knows how complex changes in heavily intertwined codebases can get, it feels like a monumental task.

Also, AFAIK Gallium has drivers for a couple older hardware that certainly don't map to the Vulkan/GCN model. I really don't know what you'd want to do for those.

[bridgman]

Vulkan and Gallium seem sufficiently far apart that it would be easier to just write new Vulkan drivers (for Nvidia and mobile chips) from scratch.

Depends on whether that's actually the case or not. I have heard confident statements made both ways.

Given that Mantle, Vulkan and Gallium3D were all intended to expose the hardware's command submission and memory mapping capabilities directly, I wouldn't expect a big difference in abstraction level. Haven't had time to go through the Vulkan spec in detail (it's surprisingly big) but from a quick read I didn't see anything contradicting that yet.

It's going to depend on whether Gallium3D or the libdrm interface ends up closer to the Vulkan API. At first glance there are a lot of common elements between the Gallium3D and Vulkan interfaces, particularly the use of constant state objects (PSO's in Vulkan).

[Ancurio]

Redefine the Gallium3D API to align better with Vulkan, adjust the existing driver accordingly, and run Vulkan over "Gallium3D v2.0".

"Optimizing" in this case would be optimizing the API design not the implementation code.

Seems like a big waste of time IMO. Vulkan and Gallium seem sufficiently far apart that it would be easier to just write new Vulkan drivers (for Nvidia and mobile chips) from scratch. We already have the Intel one, and AMD one will be made public sometime later.

[bridgman]

Redefine the Gallium3D API to align better with Vulkan, adjust the existing driver accordingly, and run Vulkan over "Gallium3D v2.0".

"Optimizing" in this case would be optimizing the API design not the implementation code.

[unixfan2001]

So why not optimize it?

He said lower, not slower.
How would you "optimise" the hierarchy of things?

[timofonic]

^That is actually quite right, vulkan would have been released long ago if it wasn't for unnecessary bureaucracies, lack of proper toolkits was OpenGL's biggest drawback. Don't know about using gallium to implement vulkan on all operating systems, is that even feasible?

timofonic Vulkan is actually slightly lower than Gallium3D on the stack, so using it to implement vulkan wouldn't work.

So why not optimize it?

[Daktyl198]

timofonic Vulkan is actually slightly lower than Gallium3D on the stack, so using it to implement vulkan wouldn't work.

[rabcor]

^That is actually quite right, vulkan would have been released long ago if it wasn't for unnecessary bureaucracies, lack of proper toolkits was OpenGL's biggest drawback. Don't know about using gallium to implement vulkan on all operating systems, is that even feasible?