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"?
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
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
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.
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.)
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.
Oh i forgot, raytracing the holy grail. So looking forward to see the Nth reflective spheres and cubes demo. Yawn.
(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.)
@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)
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)
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 !
Thanks EvilOne for all the tips
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.
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.
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.
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.
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.
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?
'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. :]
:) yzi wins
Quote:
only because the real party is inside!Nowadays, with a little bit of home coding. :]
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
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
Quote:
only because the real party is inside!
The real party was inside us all along!
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...
Quote:
Are you really saying people are somehow trying to be gatekeepers
Yes.
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.