Vulkan/DX12 are NOT good for "making games" ..

[gilesgoat]

.. they are good in case you want to get a degree in "Extreme Software Engineering / Mind Warping " and in case "you want to get something quick" .. the answer is :



"quick" as in "I write some few lines of code and I see something going on" ..

Ok .. took me basically 3 weeks nearly 1 whole month "to get somewhere that does what I need to do" ( graphically ) "thanks Xbox for forbidding anyone to use anything else but DX12" ( which actually is a good thing because forced me to learn it ) but "no thanks" you made me throw away something that I had already done was hoping to re-use it.

So DX12 is "Vulkan MS version" if they are not identical they are "almost the same" actually I THINK that maybe it's true DX12 "does some things a bit better" but oh boys I think "few things like Vulkan/DX12 give you SO MUCH rope to hang yourself with" .. basically "there's so much you can shit all over the place" ..

If you scared of structures with arrays of structures with arrays of arrays of structures and structures and more structures and pointers to structures that point to pointers to array of other structures and shit like that "don't get close to it" ..

I think "the word" on DX12/Vulkan is ".. there is a Descriptor for that !" they love Descriptors, they really do ..

I'd dare to say that while conceputally quite a few things are not very complex to understand is the implementation details where all goes really weird ( and some things are really complex to understand ) "you want to put A into B" but before you need to be sure that "A" is not really in use nor "B" and that "A" is in a state to be ready to be put into somewhere and "B" is in a state to be ready to accept something and that "A" and "B" can both "accept" what you are exchanging ..

"the heaps" .. of course all that shit need to be/go somewhere "in some memory, of the right type, in the right moment, and be sure you are not touching it while the GPU is using it" .. heap and heaps and heaps descriptors and barriers and "transitions" and the like ..

By the time you'll get "that damned triangle on the screen" you'll totally forget "why you ever wanted it in the first place"

Also must be said "one thing is do things the DX12/Vulkan way" .. but "it's all another" when you actually say ".. but I need to do things in a bit of a DIFFERENT way" ..

Anyway my call would be "reduce the number of descriptors and heaps" .. "make it all one and the same" or such .. also the way shaders are run/compiled ( "you and your strafucking 'shaders signatures' " ) should be simplified a bit.

"Does it REALLY need to be so 'overly fragmented/complicated' I mean really WTF is that HW doing with all that ??"

Anyway it's interesting ? Yes very !

Is it for "doing things quick" ? .. TOTALLY THE OPPOSITE OF IT !

Is it well documented ? .. you are KIDDING ME RIGHT ? .. NO, IT ISN'T !

It is powerful ? Well I SUPPOSE IN THEORY "you can't have more control than that" .. "can you make it really performant ?" .. I'd dare to say MAYBE ONLY if you are someone that works with AMD/NVIDIA AND knows PERFECTLY the API and what it really does and you are "a master" in using "Performance Analysis Tool" which are really complex to use/understand what is really going on.

And also "and you have a fuckload of time to spend in measuring/optimising", again "assuming you really know VERY well the ins/out of the APIs".

I can tell you IMMEDIATELY "I don't and I probably never will" ..

But I can get "something that works OK" at least for what we need.

But yeah "after DX12/Vulkam" the "only other thing I could see" is "program the GPU/CPU directly in ASM without any compiler" .. "because we are kinda like that" .. if it's not really like that it's very close to, only that you use CPP.

But yeah "if you want a degree in SW engineering then use DX12/Vulkan", "if you want to make games" it's not for you

[gilesgoat]

Fun facts yesterday by pure error ( of cut and paste of one line ) I "set a bit" of a shader telling that a Pixel/Fragment shader was instead a Vertex shader, as a result of another thing I manage to create a full graphics pipeline containing a Vertex shader ONLY and missing the pixel shader.

Someway ( still in debug mode/profile ) that DOES NOT cause ANY error, nor even a warning, the pipeline gets executed and apparently the VS too .. BUT .. there's absolutely NO graphics output !

Took me a few "PIX Captures" to understand "what the heck is going on" ..

Where does all that geom goes ? .. and in that case is the 'rasterizer' ever called ? .. it that a "legit" action with some purpose ? .. or it's just an error ? Mah .. life is full of questions ...

[_TinOmen_]

It is because of reports like this that I cannot muster the energy to look at Vulcan. I think a GPU should also have a higher level API like OpenGL immediate mode. Why should it require so much setup to just render a single triangle. When a API gets too complex then less people will use it and it increases the risk that those that do will use it incorrectly.

[gilesgoat]

It is because of reports like this that I cannot muster the energy to look at Vulcan. I think a GPU should also have a higher level API like OpenGL immediate mode. Why should it require so much setup to just render a single triangle. When a API gets too complex then less people will use it and it increases the risk that those that do will use it incorrectly.

Well I think "MUST BE SAID" all this ( DX12/Vulkam ) came probably "from coders like me" as well being "tired of black boxes" shouting for things like "we want MORE CONTROL we want to know what's going on/be able to optimize better" ..

I think at some point someone went "OH YEAH ! YOU WANT *ALL* THE TOYS ! THEN GET THEM AND NOW DO IT ALL YOURSELF !" ..

And there you have it "the GPU as it really is / works" ( surely with still quite some abstraction ) it makes you realize that :

1. "you been living in a quite cotton/wool padded world" with things like "the higher level API" like OpenGL and INDEED you are "at the BIG MERCY" of whoever wrote that OpenGL/"High Level" lib about "optimization/speed" and hoping it does what you want.

2. GPUs ARE REALLY COMPLEX BEASTS !

As I said "those libs are NOT for making games" .. Vulkan/DX12 are more for "I want to make something at extreme performance / specially suited for some app / the new mega-engine that yet does not exist / something special only for me / deep optimisation ".

They give you access to "the most low level you can so far" .. the cost is .. well "now you have the access now you do it" ..

Someone will SURELY tell you that "Higher level API" if you talk about "games" it's called "Unity/Unreal" .. and .. "most people would stop there" ..

Other would tell you that "OpenGL is MEGA SHIT and THAT IS THE REASON WHY DX12/Vulkan exist !"

And they are both "semi correct" ..

Even DX11 is not "so high level" but DX12 takes a step further.

BUT "if you want to design YOUR higher level thing" then you NEED DX12/Vulkan ..

Have a look anyway at some Vulkan examples .. they are "mind opening" .. and yes it does take "from zero to something" probably around 2000 lines of code to display ONE triangle.

But "you'll see WHY and WHY can't be less" to do so ..

In MY "high level thing" now it actually takes something like this :

Code: Select all

        ... InitTheUniverse();

	dev->DefaultTransform();
	dev->setWorld();
	dev->rotateZ(Rot_Z);
	dev->SamplerSourceIsLiteral(0, 1); // sampler, literal
	dev->UseVertexFormat(COLORVERTEX_NORMAL, PSHADER_BASETEX, VSHADER_BASENORMALTEX);
	dev->EnableAlpha(false);
	dev->EnableZbuffer(true);
	dev->UpdateWvpMatrix();

	the_cube->draw(0);

There are over 30K lines of code to get to all there and "I won't tell you how much shit happens in that draw()" but yeah "that's high level" ..

But yeah as I said "it's not to make games, it's to make Higher Level stuff "

[Dio]

Most of what you complain about goes away with task graphs, which is definitely the big thing we missed from Mantle and so all the successor APIs.

One day I'll be able to point you at the RPS release that shows it all...

[gilesgoat]

Most of what you complain about goes away with task graphs, which is definitely the big thing we missed from Mantle and so all the successor APIs.

One day I'll be able to point you at the RPS release that shows it all...

At the present my strategy is that "various functions" end up in setting some "states" in a "state block" when a draw is called it checks if there's already a "state block" that identical to the current one I built that already contains a built pipeline, if so uses that, if not grabs all the info in the SB and constructs a pipeline.

If you know in advance what you doing you could even do one ( or more ) "fake draw" in advance to construct the N pipelines you need.

About memory/buffers/descriptors/etc. I use a strategy to basically "initialise a certain max" and re-use them all the time.

This mean I put "a limit" ( at the moment ) at the max number of draw calls per frame I can do, but that's ok, for my purpose is more than fine.

I still have to work out some things better but at the time I really have NO MUCH time, I have people on my neck that just want "something that works" as soon as I can.

[GoatFoam]

I actually think vk, dx12 etc. Are ok for making games, but "making games" is the wrong level of abstraction.

They are designed to let you make the tools to make things.

You use them to back a render or compute graph API, or as a portable target for a gl implementation, or...

The important point is that you build the abstractions you need, then concentrate on not using them directly.

[Harlequin]

Giles would probably stick to ASM if it were portable.

[Misfit]

Giles would probably stick to ASM if it were portable.

I think you mean punched cards?!

[gilesgoat]

Giles would probably stick to ASM if it were portable.

I think you mean punched cards?!

SSSH I haven't made my paper tape reader yet ...

[Dio]

This thread bubbles up at just the right time! We just got RPS out of the door. In my opinion this is truly transformational to the way that graphics works today.

https://github.com/GPUOpen-LibrariesAnd ... ineShaders
https://gpuopen.com/learn/rps_1_0/
https://www.youtube.com/watch?v=PXMRUjs6SK8