Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vulkan 1.2

khronos.org

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Vulkan 1.2

#31

Post by grovesNL »

skocznymroczny wrote: post #17
bullen wrote: post #9

I'm sticking with OpenGL (ES) 3 that brought VAO for life. The returns will diminish to the point that porting or developing on new APIs does not pay for itself. I know both Jonathan Blow and Godot are clear signs that I'm wrong, but I guess we'll just have to wait and see. Until then I have my engine running on Win/x86 and the Pi 4 at good performance with minimal effort. Which is good; simple software will live for…

I'm considering switching away from OpenGL just to get rid of the global state. It's too tiring to track the OpenGL state just to realize you forgot to unset some texture in a completely different part of code. My favourite of the newest APIs is Metal, because it's very easy to jump from OpenGL (triangle in Metal is about 30 lines of code). Perhaps WebGPU is an alternative once desktop translation layer is created (G…

There is another translation layer called wgpu (https://github.com/gfx-rs/wgpu) being developed as well. It's written in Rust and has bindings for C, Rust (https://github.com/gfx-rs/wgpu-rs), and some initial support for other languages (Python, Julia, Scopes, etc.).

Dawn and wgpu have also been collaborating to create a common set of WebGPU headers. The WIP headers are located at https://github.com/webgpu-native/webgpu-headers if you're interested in contributing or following.

Re: Vulkan 1.2

#33

Post by pjmlp »

thrower123 wrote: post #25
boutad wrote: post #5

Does Vulkan have an answer to DirectX Raytracing?

There are days when I wish that DirectX was the open standard, rather than the other way around. It's such a cleaner, better designed API - quite possibly because it was not open, and so it doesn't have anywhere near as much of the design-by-committeeisms that infect OpenGL/Vulkan.

All other 3D APIs are like that, including game consoles.

OpenGL got lucky with Doom and Carmack's charisma, followed by Apple's decision to adopt it alongside NeXTSTEP.

Copland was going to use QuickDraw 3D.

Re: Vulkan 1.2

#34

Post by amaranth »

flohofwoe wrote: post #6
roenxi wrote: post #2

In case anyone isn't keeping up this is basically the next generation of OpenGl, but they've made enough changes to justify a new name. Good idea too. Make it clear that they are doing things differently.

Unfortunately the API update model hasn't changed much from OpenGL it seems ;) ...not talking about the idea to first test out new ideas in vendor-specific extensions, and then elevate them to the core, this is definitely a good idea - but about stacking new stuff on the previous API version, this approach is what turned OpenGL into the heap of accumulated cruft it is today. Direct3D instead was a new API with each n…

OpenGL deprecated the cruft in 3.0, removed it in 3.1, then added a way to get it back with the compatibility profile in 3.2. Turns out a lot of people still wanted that cruft and they were a big enough market that people listened to them. I believe it was CAD software asking for this which on Windows is the only major user of OpenGL.

Direct3D is mostly used for games so if your new game has to use a new API that's not _that_ big of a deal. You don't start from scratch every couple years with regular software though.

Re: Vulkan 1.2

#35

Post by badsectoracula »

pjmlp wrote: post #26
badsectoracula wrote: post #20

Earlier quoted context omitted.

Similar here, except i'm sticking with OpenGL 1.x (or 2.x for when i want shaders... or 3.x/4.x for when i want MORE shaders :-P), exactly because of the sheer simplicity of the API. I have written a bit of Vulkan code (i wrote this[0] the day the spec came out, after banging on it for several hours - and i found the spec quite readable, at least from the side of someone who wants to use it... someone i know who work…

Somehow ARB, and now Khronos keep forgetting that having something like MetalKit or DirectXTK as part of the specification really matters to onboard newbies. OpenInventor could have been it, but SGI had other plans for it, and no one at either ARB or Khronos actually cared about it.

It isn't just newbies, i write OpenGL code for almost 2 decades, i see no reason to do use the harder parts of the API when i can simply use the easy parts :-P.

Though i disagree with OpenInventor, it is too complex and takes too much upon itself, which few wanted - see Direct3D Retained Mode which despite being a much simpler API (both compared to D3DIM and OpenInventor) didn't see much use and in an uncharacteristic move by Microsoft (especially at the time) it was removed from Direct3D.

A better solution would have been something like GLUT, but with a few more utilities thrown in (like vector math stuff - OpenGL implementations already have the code anyway, why not expose it?). And GLUT was more popular than OpenInventor ever hoped to be despite not offering more than a few basic things.

Re: Vulkan 1.2

#36

Post by pjmlp »

badsectoracula wrote: post #35
pjmlp wrote: post #26

Earlier quoted context omitted.

Somehow ARB, and now Khronos keep forgetting that having something like MetalKit or DirectXTK as part of the specification really matters to onboard newbies. OpenInventor could have been it, but SGI had other plans for it, and no one at either ARB or Khronos actually cared about it.

It isn't just newbies, i write OpenGL code for almost 2 decades, i see no reason to do use the harder parts of the API when i can simply use the easy parts :-P. Though i disagree with OpenInventor, it is too complex and takes too much upon itself, which few wanted - see Direct3D Retained Mode which despite being a much simpler API (both compared to D3DIM and OpenInventor) didn't see much use and in an uncharacteristi…

I think that widespread adoption of middleware engines has proven that retained mode was the way to go.

The ones that don't use one, end up reimplementing their own scene graph anyway.

As for the rest, full with you.

Re: Vulkan 1.2

#37

Post by earenndil »

skocznymroczny wrote: post #17
bullen wrote: post #9

I'm sticking with OpenGL (ES) 3 that brought VAO for life. The returns will diminish to the point that porting or developing on new APIs does not pay for itself. I know both Jonathan Blow and Godot are clear signs that I'm wrong, but I guess we'll just have to wait and see. Until then I have my engine running on Win/x86 and the Pi 4 at good performance with minimal effort. Which is good; simple software will live for…

I'm considering switching away from OpenGL just to get rid of the global state. It's too tiring to track the OpenGL state just to realize you forgot to unset some texture in a completely different part of code. My favourite of the newest APIs is Metal, because it's very easy to jump from OpenGL (triangle in Metal is about 30 lines of code). Perhaps WebGPU is an alternative once desktop translation layer is created (G…

TBH, opengl has been improving in that respect. See, e.g., glTextureSubImage2D[1], which takes a pointer to the referred texture, unlike glTexSubImage2D.

1: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl...

Re: Vulkan 1.2

#38

Post by earenndil »

FpUser wrote: post #13
roenxi wrote: post #2

In case anyone isn't keeping up this is basically the next generation of OpenGl, but they've made enough changes to justify a new name. Good idea too. Make it clear that they are doing things differently.

LOL. It is not the nextgen version of GL. It is a tool that would let you make your own OpenGL. It is way too low level and takes insane amount of work comparatively to OpenGL/DirectX. Sure big engine developers would love it. Smaller guys like myself: not so much.

I'm a 'small guy'. Only person working on my game engine. Would love to add vulkan support, except my GPU is fried.

Re: Vulkan 1.2

#39

Post by rasz »

thrower123 wrote: post #23
flohofwoe wrote: post #7

Earlier quoted context omitted.

NVIDIA offers a vendor-specific extension: https://www.khronos.org/registry/vulkan/specs/1.2-extensions... I guess this will first be elevated to a vendor-neutral extension and (I guess) eventually will move into the core API.

One would have thought that they might have learned from what happened with OpenGL that this is a clusterfuck and leads to fragmentation...

They learned from CUDA that this is indeed the way to own the whole market.

Re: Vulkan 1.2

#40

Post by FpUser »

earenndil wrote: post #38
FpUser wrote: post #13

Earlier quoted context omitted.

LOL. It is not the nextgen version of GL. It is a tool that would let you make your own OpenGL. It is way too low level and takes insane amount of work comparatively to OpenGL/DirectX. Sure big engine developers would love it. Smaller guys like myself: not so much.

I'm a 'small guy'. Only person working on my game engine. Would love to add vulkan support, except my GPU is fried.

That's the difference right here. If you are in business of making engine then yes you can benefit basing your engine on something like Vulcan. To me: I am not exactly doing games/engines. I do use hardware accelerated graphics for some other type of development. OGL/DirectX are already a nuisance enough for me (just a friggin too that I want to use and forget). Having to go even lower level will not make me any happy at all. Well that is unless I find suitable rendering library. Hopefully some candidates are available now, just have to find time to evaluate.
Post reply on HN