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

Simplifying Vulkan one subsystem at a time

khronos.org

Post reply on HN
Print view View original

171–180 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#171

Post by imtringued »

kllrnohj wrote: post #33
pjmlp wrote: post #10

At least they are making an effort to correct the extension spaghetti, already worse than OpenGL. Addiitionally most of these fixes aren't coming into Android, now getting WebGPU for Java/Kotlin[0] after so many refused to move away from OpenGL ES, and naturally any card not lucky to get new driver releases. Still, better now than never. [0] - https://developer.android.com/jetpack/androidx/releases/webg...

[flagged]

The chain for GPU driver updates on Android phones is incredibly long.

Google > Phone Vendor > SoC Vendor > Arm > SoC Vendor > Phone Vendor > Android Update

and that is the happy case. The general case looks more like this:

Google > Phone Vendor > SoC Vendor > "Have you considered buying a new SoC?"

Re: Simplifying Vulkan one subsystem at a time

#172

Post by pjmlp »

Animats wrote: post #101

Not sure if this is an "oh, no" event. So this goes into Vulkan. Then it has to ship with the OS. Then it has to go into intermediate layers such as WGPU. Which will probably have to support both old and new mode. Then it has to go into renderers. Which will probably have to support both old and new mode. Maybe at the top of the renderer you can't tell if you're in old or new mode, but it will probably leak through.…

> And Apple will do something different, in Metal.

Microsoft, Sony and Nintendo as well.

Re: Simplifying Vulkan one subsystem at a time

#173

Post by imtringued »

pjmlp wrote: post #167
reactordev wrote: post #106

Earlier quoted context omitted.

I’m just pointing out that Vulkan is supported on all major modern engines, internal and public. Some also go so far as to do DX12 (fine, it’s a similar feeling API) but what’s really amazing is taking all of those games that run on OpenGL, DirectX, etc and forcing them to run on Vulkan… Proton is amazing and Wine project deserves your support.

What deserves our support is pushing for native Linux games, not helping to keep Windows status quo by making use of Wine and Proton. It is no different from being happy to use Amiga, Atari, Nintendo, PlayStation, Spectrum, C64, NeoGeo emulators on Linux.

Video games are entertainment. In the old days you inserted a cartridge or optical disc into a physical device. You play the game, finish it and then move on. They are always self contained experiences with a custom UI independent of the OS.

In the best case, explicit Linux support does not affect the experience in a positive or negative way. In the worst case, explicit Linux support means the game can't be played anymore.

Re: Simplifying Vulkan one subsystem at a time

#174

Post by pjmlp »

imtringued wrote: post #173
pjmlp wrote: post #167

Earlier quoted context omitted.

What deserves our support is pushing for native Linux games, not helping to keep Windows status quo by making use of Wine and Proton. It is no different from being happy to use Amiga, Atari, Nintendo, PlayStation, Spectrum, C64, NeoGeo emulators on Linux.

Video games are entertainment. In the old days you inserted a cartridge or optical disc into a physical device. You play the game, finish it and then move on. They are always self contained experiences with a custom UI independent of the OS. In the best case, explicit Linux support does not affect the experience in a positive or negative way. In the worst case, explicit Linux support means the game can't be played an…

> They are always self contained experiences with a custom UI independent of the OS.

Not really, as each OS and hardware provided different capabilities that made some games only possible in specific platforms.

Additionally depending on the platform, some ports were great, others were money thrown into the garbage bin.

Re: Simplifying Vulkan one subsystem at a time

#175

Post by Hendrikto »

torginus wrote: post #97
pjmlp wrote: post #52

Earlier quoted context omitted.

I did not do such claim. WebGPU on Android runs on top of Vulkan. If you knew about 3D programming on Android, you would know that there are ongoing efforts to have only Vulkan, with OpenGL ES on top. However Java and Kotlin devs refuse to bother with the NDK for Vulkan, and keep reaching for OpenGL ES instead. Please refer to Google talks on Vulkanised conferences.

Is it possible to support OpenGL on top of Vulkan well? It has been pointed out that Vulkan requires you to completely freeze and compile a graphics pipeline before using it, while OpenGL's state machine is more flexible, and the underlying hardware is somewhat more amenable to these state transitions at runtime, than the Vulkan API would suggest. Don't these compatibility layers run into issues with constant pipelin…

> Vulkan requires you to completely freeze and compile a graphics pipeline before using it

It used to be like that but it is no longer true.

Re: Simplifying Vulkan one subsystem at a time

#176

Post by xyzsparetimexyz »

kvark wrote: post #14

The main problem with Vulkan isn't the programming model or the lack of features. These are tackled by Khronos. The problem is with coverage and update distribution. It's all over the place! If you develop general purpose software (like Zed), you can't assume that even the basic things like dynamic rendering are supported uniformly. There are always weird systems with old drivers (looking at Ubuntu 22 LTS), hardware…

Isn't that just a case of being a bit hardline and saying 'this program only runs on cards/drivers with support for Vulkan 1.3?'

Re: Simplifying Vulkan one subsystem at a time

#177

Post by xyzsparetimexyz »

Animats wrote: post #154
p_l wrote: post #124

Earlier quoted context omitted.

And apparently if you do mobile you stay away from big chunk of dynamic rendering and use Vulkan 1.0 style renderpasses... or you leave performance on the floor (based on guidelines from various mobile GPU vendors)

Vulkan on mobile and web runs several years behind Vulkan on desktop. This is a problem for portable toolkits such as WGPU.

People need to stop cucking their wrapper APIs by catering to apple/mobile

Re: Simplifying Vulkan one subsystem at a time

#178

Post by phkahler »

xyzsparetimexyz wrote: post #176
kvark wrote: post #14

The main problem with Vulkan isn't the programming model or the lack of features. These are tackled by Khronos. The problem is with coverage and update distribution. It's all over the place! If you develop general purpose software (like Zed), you can't assume that even the basic things like dynamic rendering are supported uniformly. There are always weird systems with old drivers (looking at Ubuntu 22 LTS), hardware…

Isn't that just a case of being a bit hardline and saying 'this program only runs on cards/drivers with support for Vulkan 1.3?'

Now that Moores law is dead, people will be keeping hardware a lot longer.

Re: Simplifying Vulkan one subsystem at a time

#179

Post by afandian »

simonask wrote: post #145
the8472 wrote: post #113

Earlier quoted context omitted.

Most of the pixels don't change every second though. Compositors do have damage tracking APIs, so you only need to render that which changed. Scrolling can be mostly offset transforms (browsers do that, they'd be unbearably slow otherwise).

That’s not the slow part. The slow part is moving any data at all to the GPU - doesn’t super matter if it’s a megabyte or a kilobyte. And you need it there anyway, because that’s what the display is attached to. Now, the situation is that your display is directly attached to a humongously overpowered beefcake of a coprocessor (the GPU), which is hyper-optimized for calculating pixel stuff, and it can do it orders of…

I have no problem with it squeezing out the last few percent using the GPU.

But look at my CPU charts in the github link upthread. I understand that maybe that's due to the CPU emulating a GPU? But from a thousand feet, that's not viable for a text editor.

Re: Simplifying Vulkan one subsystem at a time

#180

Post by reactordev »

pjmlp wrote: post #169
reactordev wrote: post #130

Earlier quoted context omitted.

DirectX 9 is long term stable so I don't see the issue... No current gen console supports it. Mac is stuck on OpenGL 4.1 (you can't even compile anything OpenGL on a Mac without hacks). Devices like Android run Vulkan more and more and are sunsetting OpenGLES. No, OpenGL is dead. Vulkan/Metal/NVN/DX12/WebGPU are the current.

Nintendo Switch supports OpenGL, across all its models. https://www.khronos.org/conformance/adopters/conformant-prod... https://www.khronos.org/conformance/adopters/conformant-prod... https://www.khronos.org/conformance/adopters/conformant-prod...

It’s also almost 10 years old and not a current gen system.
Post reply on HN