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

191–200 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#191

Post by softfalcon »

cmovq wrote: post #123
softfalcon wrote: post #84

Earlier quoted context omitted.

I also want what you're describing. It seems like the ideal "data-in-out" pipeline for purely compute based shaders. I've brought it up several times when talking with folks who work down in the chip level for optimizing these operations and all I can say is, there are a lot of unforeseen complications to what we're suggesting. It's not that we can't have a GPU that does these things, it's apparently more of a combin…

This is true, but what the parent comment is getting at is we really just want to be able to address graphics memory the same way it's exposed in CUDA for example. Where you can just have pointers to GPU memory in structures visible to the CPU, without this song and dance with descriptor set bindings.

Ah, yeah. I see what you're saying. That is more of an open vs proprietary platform problem.

I am fairly sure that nVidia intentionally wants to keep addressable memory as a feature only for CUDA (among many other features).

Having CUDA be far superior to other shader code methods is good for vendor lock-in to their hardware, their software, their drivers, etc.

It is really sad seeing that the addressing is possible, but they won't open it up to everyone.

Re: Simplifying Vulkan one subsystem at a time

#192

Post by fc417fc802 »

bsder wrote: post #153
fc417fc802 wrote: post #114

Earlier quoted context omitted.

If you got what you're asking for you'd presumably lose access to any fixed function hardware. RE your example, knowing the data format permits automagic hardware accelerated translations between image formats. You're free to do what you're asking after by simply performing all operations manually in a compute shader. You can manually clip, transform, rasterize, and even sample textures. But you'll lose the implicit…

> If you got what you're asking for you'd presumably lose access to any fixed function hardware. Are there any fixed functions left that aren't just being implemented by the general compute shader hardware? I guess the ray tracing stuff would qualify, but that isn't what people are complaining about here.

I am under the (potentially mistaken) impression that at minimum rasterization and texture filtering retain dedicated hardware on modern cards. There's also the issue of the format you output versus the format the display hardware works in natively.

That said, I'm not clear the extent to which such dedicated functionality either already is or could be made accessible via the instruction set. But even then I'm not sure how ergonomic it would be to make use of from a shader language.

Re: Simplifying Vulkan one subsystem at a time

#193

Post by jorvi »

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.

Doing it this way actually makes games more stable on Linux. Often, Linux ports of games would be riddled with bugs because the QA just isn't worth it. Especially because desktop Linux is always in a fast flux of changes. Hence the joke that "Win32 is the only stable Linux ABI."

Now game studios can just develop for windows, work out all the bugs. And then Proton has a broad set of compatibility patches that can be applied to those Windows games.

Doing it this way also unlocks a gigantic library of old games that otherwise would have been unplayable on Linux.

So, no. No native Linux games please.

Re: Simplifying Vulkan one subsystem at a time

#194

Post by CAP_NET_ADMIN »

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…

So.. like any other Graphics/Compute API when it was actively developed.

Re: Simplifying Vulkan one subsystem at a time

#195

Post by pjmlp »

jorvi wrote: post #193
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.

Doing it this way actually makes games more stable on Linux. Often, Linux ports of games would be riddled with bugs because the QA just isn't worth it. Especially because desktop Linux is always in a fast flux of changes. Hence the joke that "Win32 is the only stable Linux ABI." Now game studios can just develop for windows, work out all the bugs. And then Proton has a broad set of compatibility patches that can be a…

Thus keeping Windows the main platform for game studios and gamers.

Enjoy those 3% market share.

Re: Simplifying Vulkan one subsystem at a time

#196

Post by socalgal2 »

pjmlp wrote: post #158
socalgal2 wrote: post #152

Earlier quoted context omitted.

This is kind of ridiculous take You can use wgpu or dawn in a native app and use native tools for GPU debugging if that's what you want You can then take that and also run it in the browser, and, you can debug the browser in the same tools. Google it for instructions The positive things about WebGPU is it's actually portable, unlike Vulkan. And, it's easy to use, unlike Vulkan.

WebGPU is JavaScript + WebGPU, it has nothing to do with wgpu Rust extensions for native coding, other than sharing a similar API surface. The very fact that you are suggesting this as workaround proves how bad the tools are.

WebGPU is not just JavaScript + WebGPU. Whole native like apps are being written using WGPU and Dawn which then can be compiled for the Web.

Here's one:

https://unity.com/products/unity-studio

Here's another

https://www.adobe.com/products/photoshop/online.html

They shipped. So I guess waiting tools wasn't required

Re: Simplifying Vulkan one subsystem at a time

#197

Post by adithyassekhar »

dyingkneepad wrote: post #125
Octoth0rpe wrote: post #25

Earlier quoted context omitted.

> we should more readily abandon GPU vendors This was so much more practical before the market coalesced to just 3 players. Matrox, it's time for your comeback arc! and maybe a desktop pcie packaging for mali?

The market is not just 3 players. These days we have these things called smartphones, and they all include a variety of different graphics cards on them. And even more devices than just those include decently powerful GPUs as well. If you look at the Contributors section of the extension in the post, and look at all the companies involved, you'll have a better idea.

There are still three players in smartphones realistically.

ARM makes their Mali line, which vendors like Mediatek license and puts straight on their chips.

Qualcomm makes their custom Adreno gpus. (Derived from Radeon Mobile). They won't sell it outside snapdragon.

Samsung again licensed Mali from ARM, but in their flagship exynos's they use AMD's gpus. They won't sell it outside exynos.

PowerVR makes gpus that are so outdated with features that Pixel 10 phones can't even run some benchmarks.

And then there's apple.

Re: Simplifying Vulkan one subsystem at a time

#198

Post by reactordev »

pjmlp wrote: post #181
reactordev wrote: post #180

Earlier quoted context omitted.

It’s also almost 10 years old and not a current gen system.

Owners of Switch 2 beg to differ. And secondly that doesn't matter when we look at the amount of sold units. Valve can only dream to sell a quarter of those numbers.

Valve owns the market, it doesn't have to...

Also, if we're talking Switch 2, you have Vulkan support on it so odds are you would choose 2x-10x performance gains over OpenGL. It isn't that powerful. My 6 year old iPhone is on par.

Re: Simplifying Vulkan one subsystem at a time

#199

Post by BadBadJellyBean »

esseph wrote: post #46
BadBadJellyBean wrote: post #34

Earlier quoted context omitted.

You don't have to run LTS. There is a new release every 6 months.

I've been running Linux for a very long time. Ubuntu has never ever been the most stable or useful distro. What it did have was apt and more up to date stuff than debian. I would never willingly choose Ubuntu if allowed other options (Fedora, Debian, maybe CoreOS, etc)

I have been running Linux for a long time as well (I used Mandrake linux) and I find Ubuntu mostly nice. What I would not say is that it is not stable or useful. The long LTS cadences give it much time to be very stable and you can also be more on the edge when you use the in between versions.

So I'd say it is very much a personal preference but just saying it is not stable is just not generally true. I could say the same about Fedora that shipped graphics drivers so new that all my software was broken for a while. To each their own I guess.

Re: Simplifying Vulkan one subsystem at a time

#200

Post by jorvi »

reactordev wrote: post #198
pjmlp wrote: post #181

Earlier quoted context omitted.

Owners of Switch 2 beg to differ. And secondly that doesn't matter when we look at the amount of sold units. Valve can only dream to sell a quarter of those numbers.

Valve owns the market, it doesn't have to... Also, if we're talking Switch 2, you have Vulkan support on it so odds are you would choose 2x-10x performance gains over OpenGL. It isn't that powerful. My 6 year old iPhone is on par.

People generally don't realize how much more CPU efficient calls are with Vulkan, DX12 or Metal. And especially on handhelds, the SoC is always balancing its power envelope between the CPU and GPU so the more efficient you are with the CPU, the more power you can dedicate to the GPU.
Post reply on HN