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

181–190 of 200 posts

Re: Simplifying Vulkan one subsystem at a time

#181

Post by pjmlp »

reactordev wrote: post #180
pjmlp wrote: post #169

Earlier quoted context omitted.

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.

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.

Re: Simplifying Vulkan one subsystem at a time

#182

Post by jsheard »

afandian wrote: post #179
simonask wrote: post #145

Earlier quoted context omitted.

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.

Yeah LLVMpipe means it's emulating the GPU path on the CPU, which is really not what you want. What GPU do you have out of interest? You have to go back pretty far to find something which doesn't support Vulkan at all, it's possible that you do have Vulkan but not the feature set Zed currently expects.

Re: Simplifying Vulkan one subsystem at a time

#183

Post by afandian »

jsheard wrote: post #182
afandian wrote: post #179

Earlier quoted context omitted.

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.

Yeah LLVMpipe means it's emulating the GPU path on the CPU, which is really not what you want. What GPU do you have out of interest? You have to go back pretty far to find something which doesn't support Vulkan at all, it's possible that you do have Vulkan but not the feature set Zed currently expects.

It was ASUS GeForce GT710-SL-2GD5 . I see some sources putting at at 2014. That's not _recent_ recent, but it's within the service life I'd expect.

(Finger in the air, I'd expect an editor to work on 20 year old hardware.)

Sold it ages ago. New one (Intel) works fine.

I was running Ubuntu. I forget which version.

Re: Simplifying Vulkan one subsystem at a time

#184

Post by jsheard »

afandian wrote: post #183
jsheard wrote: post #182

Earlier quoted context omitted.

Yeah LLVMpipe means it's emulating the GPU path on the CPU, which is really not what you want. What GPU do you have out of interest? You have to go back pretty far to find something which doesn't support Vulkan at all, it's possible that you do have Vulkan but not the feature set Zed currently expects.

It was ASUS GeForce GT710-SL-2GD5 . I see some sources putting at at 2014. That's not _recent_ recent, but it's within the service life I'd expect. (Finger in the air, I'd expect an editor to work on 20 year old hardware.) Sold it ages ago. New one (Intel) works fine. I was running Ubuntu. I forget which version.

> It was ASUS GeForce GT710-SL-2GD5 . I see some sources putting at at 2014. That's not _recent_ recent, but it's within the service life I'd expect.

That's pretty old, the actual architecture debuted in 2012 and Nvidia stopped supporting the official drivers in 2021. Technically it did barely support Vulkan, but with that much legacy baggage it's not really surprising that greenfield Vulkan software doesn't work on it. In any case you should be set for a long time with that new Intel card.

I get where you're coming from that it's just a text editor, but on the other hand what they're doing is optimal for most of their users, and it would be a lot of extra work to also support the long tail of hardware which is almost old enough to vote.

Re: Simplifying Vulkan one subsystem at a time

#185

Post by qskousen »

tonis2 wrote: post #41

I wish they would just allow us to push everything to GPU as buffer pointers, like buffer_device address extension allows you to, and then reconstruct the data to your required format via shaders. The GPU programming seems to be both super low level, but also high level, cause textures and descriptors need these ultra specific data format's, and then the way you construct and upload those formats are very complicated…

Just yesterday I watched this video: https://m.youtube.com/watch?v=7bSzp-QildA I am not a graphics programmer, but from what I understood I think he talks about doing what you are describing with Vulkan.

Re: Simplifying Vulkan one subsystem at a time

#186

Post by xyzsparetimexyz »

phkahler wrote: post #178
xyzsparetimexyz wrote: post #176

Earlier quoted context omitted.

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.

I have a 12 year old GTX 750 and it supports Vulkan 1.4.

Re: Simplifying Vulkan one subsystem at a time

#187

Post by kllrnohj »

imtringued wrote: post #171
kllrnohj wrote: post #33

Earlier quoted context omitted.

[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?"

long is different from won't come

Re: Simplifying Vulkan one subsystem at a time

#188

Post by afandian »

jsheard wrote: post #184
afandian wrote: post #183

Earlier quoted context omitted.

It was ASUS GeForce GT710-SL-2GD5 . I see some sources putting at at 2014. That's not _recent_ recent, but it's within the service life I'd expect. (Finger in the air, I'd expect an editor to work on 20 year old hardware.) Sold it ages ago. New one (Intel) works fine. I was running Ubuntu. I forget which version.

> It was ASUS GeForce GT710-SL-2GD5 . I see some sources putting at at 2014. That's not _recent_ recent, but it's within the service life I'd expect. That's pretty old, the actual architecture debuted in 2012 and Nvidia stopped supporting the official drivers in 2021. Technically it did barely support Vulkan, but with that much legacy baggage it's not really surprising that greenfield Vulkan software doesn't work on…

I initially misremembered the age of the card, but it was about that old when I bought it.

My hope was that they would find a higher-level place to modularize the render than llvmpipe, although I agree that was unreasonable technical choice.

Once-in-a-generation technology cliff-edges have to happen. Hopefully not too often. It's just not pleasant being caught on the wrong side of the cliff!

Thanks for the insights.

Re: Simplifying Vulkan one subsystem at a time

#189

Post by sxzygz »

flohofwoe wrote: post #164
sxzygz wrote: post #141

Earlier quoted context omitted.

I don’t know which of my detractors to respond to, so I’ll respond here. It should be clear that I’m only interested in compute and not a GPU expert. GPUs, from my understanding, have lost the majority of fixed-function units as they’ve become more programmable. Furthermore, GPUs clearly have a hidden scheduler and this is not fully exposed by vendors. In other words we have no control over what is being run on a GPU…

> GPUs, from my understanding, have lost the majority of fixed-function units as they’ve become more programmable. That would be nice but doesn't match reality unfortunately, there are even new fixed-fuction units added from time to time (e.g. for raytracing). Texture sampling units also seem to be critical for performance and probably won't go away for a while. It should be possible to hide a lot of the fixed-functi…

Thanks for the link to the post. I also watched her talk posted elsewhere in these comments. We’re lucky to have people like her doing the hard work for free software.

> most of the reasons are probably not even technical, but legal/strategic - patents and stuff

I think fighting for specified interoperable interfaces is important and we must be vigilant again forces that undermine this, either knowingly or through ignorance.

Re: Simplifying Vulkan one subsystem at a time

#190

Post by marcthe12 »

6SixTy wrote: post #55
zamalek wrote: post #20

Earlier quoted context omitted.

> Ubuntu LTS This is why I try to encourage new Linux users away from Ubuntu: it's a laggard with, often important, functionality. It is now an enterprise OS (where durability is more important than functionality), it's not really suitable for a power user (like someone who would use Zed).

My understanding with Mesa is that it has very few dependencies and is ABI stable, so freezing Mesa updates is counterproductive. I'm not sure about Snaps, but Flatpak ships as it's own system managing Mesa versions.

Unfornately that is llvm which is not stable (abi break every 6 months).
Post reply on HN