pouët.net

+1



What about building a fresh API without all that old batshit crap, you enabler. I don't see no fixed pipe in DX10+ either.

Or in the core profile of OpenGL/OpenGL ES 2.0+ for that matter.

I suppose there may be room for an independent 'legacy support' library, which could be open source. But it should not be part of OpenGL/Vulkan itself. Just some middleware. In fact, if you want it, why not build it yourself?
It can just be a simple wrapper over the modern shader/vertexbuffer functionality.

This is precisely what I meant.

So a would be could be "independent" primitive batcher (a task that in any engine is best implemented then and there to fit in specifically).

The only target audience really would be entry-level graphics programming classes, and even that's debatable.

May I propose 'libnehe' as project name then?

What, they have no connection to the demo scene?

Eh, there's a lot of use cases where you don't need to render all that many primitives. If you just want to render a couple hundred solid-colored rectangles, having to go through the trouble of setting up shaders & stuff causes so much cognitive friction that you'd often rather just skip it (or do it in software).

For prototyping a lot of things, the immediate mode glBegin stuff is fine. Feel free to disagree.

Well off the bat:

a) If you're just rendering a few hundred solid-colored rectangles and just that, it might be time to reconsider your strategy if you're working at C(++) & API level and pick a more suitable higher level solution instead. We don't write our build scripts in assembler either, right?

Also, if you really insist: take one of the hundreds of examples out there as a basis. Like expanding on a DX demo.

I have a fair bit of first-hand experience in picking the lower (or in the 90s, lowest) language for often pretty contained tasks that befit a higher level language solution. And I generally hate to see others replicate that stupidity. And I stress generally since I'm known for my fondness of other people.

b) Khronos and affiliates should focus on fixing their halfway broken APIs (which they now seem to take another step towards) instead of thinking "hey, well, Microsoft had D3DX for years and now deprecated it -- perhaps now it's our turn to do the same just to in 10 years discover it's asinine to promote and incorporate it as part of the API?".

In fact, D3DX is a nice analogy. It was a fine, handy dandy library that saw (and still sees) good use. However, it was never supposed to be taken as a serious developer's backbone for graphics programming.

So now there's DirectXTK, which ain't official nor independent, but works.

See I'm not against the idea of the library, I just think Khronos and affiliates should drop it as part of their business, not even third-tier.

I doubt it. Vulkan is very low-level. In one of the Khronos presentations, there was a question from the audience about how big a "Hello World" program (i.e. drawing a textured triangle) would be in Vulkan. The answer that one of the presenters gave was: 600 lines.

Even if that example does maybe more than would be required in a 4k, the answer still says a lot about the amount of setup code needed to get even the simplest things running.

Was any context given alongside that claim? Or even better, an example viewing? 600 lines of code doesn't necessarily mean all that much (though sure, for 4KB) and I sincerely wonder what's being set up there and on which platform.

Not that it strikes me as much, setting up the old NV20 (co-wrote a D3D replacement for Xbox back in the days) manually to switch modes, initialize pushbuffers and eventually draw a triangle was more afair. Though that was 100% lowlevel (like PS3 libgcm), not sure where exactly Vulkan floats in that spectrum.

Sure, here are my initial thoughts on vulkan: https://codelab.wordpress.com/2015/03/06/initial-thoughts-on-vulkan/

It seems that MS is thinking more or less the same about DX11 and DX12.
They have planned a D3D11.3 update that will bring some new features from DX12 to the DX11 API.
Other than that, they have said at some point that they don't think DX12 may be the right API for everyone.
It takes a lot of work and knowledge to set up a proper DX12 renderer, because less is done by the driver/runtime, and more has to be done by the application explicitly.
So DX11 may co-exist with DX12 as a more accessible API.

Based on the concrete features and general philosophy mentioned in the talk, my guess (and it is just a guess) is that a basic Vulkan application (spinning, textured cube) would need to go through approximately these steps:

Prerequisites:

Compiled shaders (in SPIR-V format)
Texture data
Vertex data

General setup:

Query available graphics adapters
Select graphics adapter
Acquire graphics adapter
Query available dispatch queues
Select dispatch queue
Acquire dispatch queue
Query available presentation modes
Select presentation mode
Create backbuffer objects (one per buffer, i.e. typically 2 or 3)
Query backbuffer memory requirements
Allocate memory for backbuffers
Attach memory to backbuffer objects
Create depth buffer object
Query depth buffer memory requirements
Allocate memory for depth buffer
Attach memory to depth buffer object
Create command buffer

Specific setup:

Create texture object
Query texture memory requirements
Allocate memory for texture
Attach memory to texture object
Query texel layout
Reorder texels according to texel layout
Upload texels to texture memory
Create vertex buffer object
Query vertex buffer memory requirements
Allocate memory for vertex buffer
Attach memory to vertex buffer object
Upload vertex data to vertex buffer memory
Create constant buffer object
Query constant buffer memory requirements
Allocate memory for constant buffer
Attach memory to constant buffer object
Create pipeline object
Initialize vertex shader object
Attach vertex shader object to pipeline
Initialize pixel shader object
Attach pixel shader object to pipeline
Define vertex layout
Attach vertex layout to pipeline
Define sampler
Attach sampler to pipeline
Define other state (depth, stencil, blend, etc.)
Attach other state to pipeline
Finalize pipeline object

Per frame:

Wait until current backbuffer is available for writing (no longer being presented)
Define render pass (input texture, output buffers)
Start render pass
Upload data to constant buffer (transformation matrices, etc.)
Start command buffer
Command: Set pipeline object
Command: Set vertex buffer
Command: Set constant buffer
Command: Set texture
Command: Draw
End command buffer
Submit command buffer to dispatch queue
End render pass
Set current backbuffer to be presented when ready


The exact mechanism for waiting for availability of the backbuffer could be a number of different things, i.e. it could be a GPU-side barrier rather than a CPU wait, though a CPU wait is presumably necessary at some point in order not to get too far ahead. In any case, my guess is that this mechanism will be under the explicit control of the application.

Some things not included:
- Cleanup
- Querying available backbuffer/texture formats (presumably there are some guaranteed available formats to choose from)
- Computation of transformation matrices

And I have probably forgotten something essential in there somewhere. :)

My first impression is that the list is not that different from your average D3D11/OGL4.x initialization.

The essence is the same, yes, but the explicit memory allocation and synchronization blows up the Vulkan version quite a bit, I suspect.

Now that I've watched the presentation, the person said that the 600 lines are equivalent to doing glBegin(GL_TRIANGLES); glVertex3f(...); ... glEnd();.

I'm sensing some open source helper toolkits in vulkan's future.. but to my original question, vulkan doesn't look like 4k heaven.

If you allow some abstraction you could say the same goes for any 4K really. Me setting up MCGA in DOS is 2 lines of code but it does a whole lot more than that under the hood, so seeing that as an essential platform call that shouldn't count as a size cheat you can see how that scales upwards to Windows, GL, D3D et cetera.

And let's all not forget that Vulkan, or any other API, is designed respecting the needs of the outskirts of a subculture :)

This video about vulkan and spir-v just popped up on the Official Khronos OpenGL twitter feed.

Join Khronos Group members for details about Vulkan, previously known as glNext, and the new SPIR-V intermediate language. Many of the speakers and demos presented at the Valve session were on hand for in-depth Q&A.

Vulkan and SPIR-V session