Where is vulkan!?

[rabcor]

Khronos did announce a release date of Q4 2015 for Vulkan, there are exactly 22 days before this period is over and we still don't even have a concrete release date. I don't like being kept out of the loop like this, will Vulkan make it's debut in time for Q4 2015? Or will it be announced as "delayed" in the coming weeks, or will it just be announced delayed on the 31st?

If they are sticking to the release date of December 2015, then vulkan should by now for all intents and purposes already be ready in an RC state, if it does not yet have an RC, just admit already that you'll miss the mark and have to release it in Q1 or Q2 of 2016, but don't keep us out of the loop like this.

I know it might be hard to coordinate with so many separate parties within Khronos that are involved with Vulkan to settle on a concrete release date or whether or not it's ready, but just do it already...

[phoronix]

Phoronix: Intel Open-Source Developer Talks About Vulkan

Jason Ekstrand of Intel's Open-Source Technology Center had a main track presentation on Saturday at FOSDEM about Vulkan...

http://www.phoronix.com/scan.php?page=news_item&px=FOSDEM-2016-Intel-Vulkan

[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]

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]

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.

[timofonic]

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

They ought to make the United Confederation of Interstellar Planets.