pouët.net

OpenGL or DirectX for 64k PC

category: code [glöplog]
Quote:
using Open Source technology always better then MS corporation(especially for non U.S. members)


MS last year did more for open source than all the penguins of the Arctic ever did!
Quote:
porting Doom3 engine, and learning Vulkan at same time, cost 3 month of work.


yup, exactly - it took 3 months for a seasoned professional game developer that has years (decades?) of full-time development experience.

Kusma worked years in graphics driver development for ARM/Mali.

Danilw: Do you have the same kind of experience? Isn't it more likely that you will give up after 3 weeks anyway, because you get "bored"?
added on the 2020-03-30 16:13:55 by arm1n arm1n
who needs Vulkan when there's Zink?!?!??!
Stay with GL if it works out for you. I have a personal hate for that API, don't ask. My own D3D12 experience was as much fun as the first use of D3D9. So much ease of use. If you want to go with D3D12 or Vulkan, I would recommend D3D12 because it is so easy.

For the start some simple things:

- Don't spend your time on sophiscated heap management. Just carve out big enough descriptor heaps times buffered frames, and if you are over the limit, log it and bail out.

- Don't spend your time on resource views. Just splay them on the above heap.

- Don't spend your time on resources and resource heaps. Use committed resources and call it a day.

- Don't spend your time thinking too much about root signatures. Make three or four big enough for your needs, but don't go over board.

- Don't spend your time thinking too much about upload heap management. Just allocate enough or on demand. A simple linked list will do wonders.

- Don't spend your time thinking too much about constant buffers. Splay them on the upload heap and call it a day again.

- Don't spend your time thinking too much about constants anyways. Spit them into the root signature if unsure. Especially nVidia loves this.

Pipeline states are a pain in the ass because you must know before to what target/depth format you are render. Hashing is your friend here. Even a simple linked list you create at start will do. Creating them will block hard. Driver internal shader compilation will happen here.

Happy Coding :-D
added on the 2020-03-30 19:29:02 by EvilOne EvilOne
Quote:
What aspect of vulkan/dx12 do you think will help with that significantly in the next months?

Hardware support for ray-tracing is an obvious use case.
added on the 2020-03-30 20:44:42 by Zavie Zavie
Quote:
Then let me rephrase: Which aspect of dx11 currently severely limits you in your demomaking / effects invention? What aspect of vulkan/dx12 do you think will help with that significantly in the next months?

I think the point was that it's not necessary to squeeze every single drop out of the previous generation before moving on to the status quo:
Quote:
Not investing time in dying technology

(Sorry for repeating, but the rephrasing still misses the point.)
added on the 2020-03-30 21:56:33 by absence absence
So you don‘t invest time in dying technology, but you invest time in re-implementing the same stuff you had before on top of new technology whose main strengths (multi-threaded rendering) you are most likely never going to use. Smart move.

Oh i forgot, raytracing the holy grail. So looking forward to see the Nth reflective spheres and cubes demo. Yawn.
added on the 2020-03-30 22:12:25 by arm1n arm1n
(guys, i‘m just teasing you. do whatever you like of course. i’m just trying to propose an alternative view and give some food for thought.)
added on the 2020-03-30 22:17:13 by arm1n arm1n
@EvilOne I very disagree with your tips, AMD and Nvidia does have Very different hardware limitation for everything, for number of supported command buffers, for size of max data per frame that can be send to GPU(that very limited, bytes)
size and format of images, shaders specefication for vendor...

writing anything more complicated than "single triangle" already explode code and it very easy to make it "only one <developer GPU> application" because you do not check limitations

you can not write on DX12 or Vulkan in DX11/GLES3 way, where you expect to application crash/not work at all when you code something wrong, in Vulkan/DX12 it does not send any warning and crashes, it may even just work when you mis half on needed code(and not work on any other GPU after driver update)
added on the 2020-03-30 23:54:34 by Danilw Danilw
I just tested to import some very basic sample of dx12 code into my opengl player (just clearing a render target) and this added 3kb on uncompressed exe ! I think I will give a try !
added on the 2020-03-31 09:21:04 by lamogui lamogui
Thanks EvilOne for all the tips
added on the 2020-03-31 09:23:13 by lamogui lamogui
But to be true, there is no point in switching to D3D12. If OpenGL works out well enough for you, I would stay with it. D3D11 is a good alternative.

The thing is, if you will start from scratch just for fun. Why not. But for being productive I would use whatever feels simple to use and comfortable.
The good old way of GL dial-and-switches isn't that bad when doing an 64K. You don't have to load and use every function pointer under the sun. The nice thing with OpenGL - you can give a shit about constant buffers - just use glUniform and call it a day.

D3D11 is a viable alternative and won't go away within the next 10 years. A battle proven API with only minor quirks. Currently the best out there.
added on the 2020-03-31 13:18:23 by EvilOne EvilOne
Allow me to emphasize that keeping things simple is key. You're making a 64K, not writing avionics. Set a target platform (your own rig) and bail if you run out of whatever without doing jack shit to "smart" manage.
added on the 2020-03-31 17:58:26 by superplek superplek
As a rule of thumb, you should allocate 95% of your time and resources to evaluating technology choices such as DirectX vs OpenGL. Once that's done right, the actual prod practically creates itself with a little bit of party coding.
added on the 2020-03-31 21:43:26 by yzi yzi
Quote:
Allow me to emphasize that keeping things simple is key. You're making a 64K, not writing avionics. Set a target platform (your own rig) and bail if you run out of whatever without doing jack shit to "smart" manage.


The "problem" is that some groups and people keep trying to make it rocket science.

They keep trying to do everything with demotools, Vulkan, and even DX12.

Sure, I am in no way shape or form "elite", but really other people shouldn't let others bully them into how they contribute. They are not some gatekeepers.

No matter how much they want themselves to be.
added on the 2020-03-31 21:45:15 by mudlord mudlord
mudlord: Dude, this is a thread asking for advice on this very matter. Are you really saying people are somehow trying to be gatekeepers by trying to provide advice when it's requested?
added on the 2020-03-31 22:01:53 by kusma kusma
'Gatekeeper' would be a lovely name for the next run of the mill raymarching 4k!
Quote:
As a rule of thumb, you should allocate 95% of your time and resources to evaluating technology choices such as DirectX vs OpenGL. Once that's done right, the actual prod practically creates itself with a little bit of party coding.


Nowadays, with a little bit of home coding. :]
added on the 2020-04-01 12:16:30 by ham ham
:) yzi wins
added on the 2020-04-01 12:24:23 by arm1n arm1n
Quote:
Nowadays, with a little bit of home coding. :]
only because the real party is inside!
added on the 2020-04-01 14:00:06 by ferris ferris
one I can say for sure
Vulkan community is not friendly at all
https://www.reddit.com/r/vulkan/comments/fskrs6/amd_vulkan_drivers_has_lots_of_very_critical_bugs/ lots of removed comments and people do not understand something more complicated then HelloWorld
added on the 2020-04-01 16:10:15 by Danilw Danilw
Quote:
only because the real party is inside!


The real party was inside us all along!
added on the 2020-04-01 21:55:12 by Spenot Spenot
Quote:
Not investing time in dying technology

OpenGL is dying since more than 20 years now.
If it keeps dying for another 20 years, it's probably not much of a problem to care about...
added on the 2020-04-02 12:19:08 by hfr hfr
Quote:
Are you really saying people are somehow trying to be gatekeepers


Yes.
added on the 2020-04-02 13:02:50 by mudlord mudlord
Quote:
'Gatekeeper' would be a lovely name for the next run of the mill raymarching 4k!


Wouldn't be indeed.

"insert some groupname here" == instant compo winner.
added on the 2020-04-02 13:05:30 by mudlord mudlord

login