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

RenderingNG: An architecture that makes and keeps Chrome fast for the long term

blog.chromium.org

Post reply on HN
Print view View original

151–160 of 161 posts

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#151

Post by Jweb_Guru »

Ygg2 wrote: post #150
skitter wrote: post #120

Earlier quoted context omitted.

Apparently wgsl was created because SPIR-V isn't well suited for being an intermediate representation to target graphics APIs other than Vulkan itself. Some notes of intrest: https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html

Had a discussion with that colleagues I spoke. He pointed me to some interesting discussion in FNA Discord. Basically bunch of stuff listed in that blog are Rust specific uint vs int. Others are kinda standards problem of undefined behavior being well - undefined. Gamedevs are used to this, but not Rust devs. I'm reminded of xkcd https://xkcd.com/927/ So rather than relying on previous work, they wrote their own some…

None of what's outlined on that blog has anything to do with Rust. And wgpu has to validate code for undefined behavior because it needs to run in browsers, as well as translate it to other backends that aren't SPIRV--it again doesn't really have anything to do with Rust. In fact according to the Rust memory model, most UB on the GPU would technically be okay (though obviously not ideal) but not in the context of a browser. So just saying "eh that stuff is undefined" or "this is just Rust stuff" doesn't really address the issues outlined there.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#152

Post by Ygg2 »

Jweb_Guru wrote: post #151
Ygg2 wrote: post #150

Earlier quoted context omitted.

Had a discussion with that colleagues I spoke. He pointed me to some interesting discussion in FNA Discord. Basically bunch of stuff listed in that blog are Rust specific uint vs int. Others are kinda standards problem of undefined behavior being well - undefined. Gamedevs are used to this, but not Rust devs. I'm reminded of xkcd https://xkcd.com/927/ So rather than relying on previous work, they wrote their own some…

None of what's outlined on that blog has anything to do with Rust. And wgpu has to validate code for undefined behavior because it needs to run in browsers, as well as translate it to other backends that aren't SPIRV--it again doesn't really have anything to do with Rust. In fact according to the Rust memory model, most UB on the GPU would technically be okay (though obviously not ideal) but not in the context of a b…

Admittedly I don't know kvark, but some of his statement there were wrong, in a way that gives impression he didn't do much 3D programming before hand. That's why I imagine he worked on the If one were to go through a point by point rebuttal, it'd go like this:

- Not knowing you need to have entry point for the shader to be executed.

- kvark's complaint about OpFmod being misnamed are kinda missing the point, % isn't the mod operator but remainder operator (in C/C++)

- https://mobile.twitter.com/TheSpydog/status/1232819839888166... You know it's a pretty bad idea when Unity and Adobe are begging you not to do this.

- I mean what you prefer to write?

GLSL:

    int a = 2
    for (int i = 0; i
WSGL:

    const a: i32 = 2;
    var i : i32 = 0;
    loop() {
       break if (i >= 4);

       a = a * 2;
    
       continuing {
          i = i + 1;
       }
    }

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#153

Post by Jweb_Guru »

Ygg2 wrote: post #152
Jweb_Guru wrote: post #151

Earlier quoted context omitted.

None of what's outlined on that blog has anything to do with Rust. And wgpu has to validate code for undefined behavior because it needs to run in browsers, as well as translate it to other backends that aren't SPIRV--it again doesn't really have anything to do with Rust. In fact according to the Rust memory model, most UB on the GPU would technically be okay (though obviously not ideal) but not in the context of a b…

Admittedly I don't know kvark, but some of his statement there were wrong, in a way that gives impression he didn't do much 3D programming before hand. That's why I imagine he worked on the If one were to go through a point by point rebuttal, it'd go like this: - Not knowing you need to have entry point for the shader to be executed. - kvark's complaint about OpFmod being misnamed are kinda missing the point, % isn't…

kvark is a GPU expert who's worked on GPU programming, 3D games, and GPU standards for years now. And he's not the only one working on naga, either.

I'm also really not sure how you got the first point from what he wrote. He was not saying he was surprised to find "you need to have an entry point" he was saying the restriction made no sense, and that existing tools didn't even take advantage of having more than one entry point due to driver bugs.

The rest of your points are basically just opinions masquerading as something else. In any case I don't actually care how hard WGSL is to write, because I don't have to write it (you can go through a translation layer). What I'm not going to do is pretend that SPIR-V is a great choice for this intermediate layer solely on the basis of what I've heard from other graphics people who haven't actually tried to use it for that purpose--which is exactly what the article is about.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#154

Post by hazz99 »

fouric wrote: post #134
hazz99 wrote: post #89

Earlier quoted context omitted.

I really don’t think this is such a bad thing. It makes it much easier to develop software and has helped result in the explosion of awesome digital products that we see today. I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though. But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.

It's not just memory efficiency - webtech applications are significantly more CPU-hungry than desktop applications. > It makes it much easier to develop software I've never seen compelling evidence that this is the case. Every time this argument is made, it seems to be by a webdev who has no significant experience with building desktop applications. Sure, if you already know webdev, it's easy to build things with web…

I think that is the wrong question to ask. Web apps are more productive, almost by default, because you don’t need to rewrite the application for each distribution target.

I can build a web application and deploy it on the web, on Windows, on Mac OSX, on iOS, on Android, on Linux, immediately. With minimal extra effort, assuming I know what I’m doing.

Correct me if I’m wrong (it’s possible), but I don’t think that’s at all possible with native libraries, or even cross-platform frameworks like Qt.

It also means companies don’t have to hire multiple product teams. They can hire one team.

So even if native development is 10-20% more productive (I’d disagree, but for arguments sake), it’d still fall short.

Webtech might score low on the CPU efficiency scale, but it scores very high when it comes product timelines, headcount, payroll and (arguably) ease-of-hiring.

This is why I think webtech almost always makes more business sense. At least for your typical SaaS product.

This is why I’m excited for WASM. We might finally have the tooling for truly cross-platform development without sacrificing efficiency/low level control.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#155

Post by Ygg2 »

Jweb_Guru wrote: post #153
Ygg2 wrote: post #152

Earlier quoted context omitted.

Admittedly I don't know kvark, but some of his statement there were wrong, in a way that gives impression he didn't do much 3D programming before hand. That's why I imagine he worked on the If one were to go through a point by point rebuttal, it'd go like this: - Not knowing you need to have entry point for the shader to be executed. - kvark's complaint about OpFmod being misnamed are kinda missing the point, % isn't…

kvark is a GPU expert who's worked on GPU programming, 3D games, and GPU standards for years now. And he's not the only one working on naga, either. I'm also really not sure how you got the first point from what he wrote. He was not saying he was surprised to find "you need to have an entry point" he was saying the restriction made no sense, and that existing tools didn't even take advantage of having more than one e…

Kvark's good, but he's still fallible. And I don't know what games he made, but I can tell you, others that had experience with shipping games/software, laughed his articles out loud.

> he was saying the restriction made no sense

So presented with reality of a complex, buggy drivers, his solution is - to ignore it? Wow imagine in UTF-8 people just said, yeah 8bit 0 are ok everywhere and caused hundred of billions of lines of code to be written to deal with null mid UTF8 stream.

> I don't actually care how hard WGSL is to write

Awfully dismissive. Well, ok, you won't have to write it but someone will. And those someone are going to curse whoever wrote that abomination of a spec.

A spec that: - That doesn't respect backwards compatibility - Looks like pure torture to write in - Misunderstands some part like OpRem

I'm not very confident in it to be honest. Looks to me just another overly elaborate moat for browser implementors.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#156

Post by nikolay »

fouric wrote: post #141
nikolay wrote: post #140

Earlier quoted context omitted.

Yet, nothing beats Safari on MacBooks!

I'm pretty sure because Apple is doing full-stack optimization. I'm willing to bet you that Safari has a worse trade-off than Chromium or Firefox on non-Apple platforms.

But we're talking about drastic differences in memory and CPU usage, not minor differences.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#157

Post by fouric »

nikolay wrote: post #156
fouric wrote: post #141

Earlier quoted context omitted.

I'm pretty sure because Apple is doing full-stack optimization. I'm willing to bet you that Safari has a worse trade-off than Chromium or Firefox on non-Apple platforms.

But we're talking about drastic differences in memory and CPU usage, not minor differences.

How does that have anything to do with my point? I said that Safari has an advantage over Chrome on Apple hardware only because it has an integration advantage. Chrome is still faster on most other platforms... including non-Google ones, like Windows and Linux - which the majority of users use. That is impressive. Meanwhile, there is nothing special about a browser that does best on hardware made by the same developer as it.

Plus, both Firefox and Chrome have significantly more useful features than Safari on all platforms.

Safari only wins when you care about pure performance on specifically Apple hardware without concern for features or add-ons. Not commendable.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#158

Post by nikolay »

fouric wrote: post #157
nikolay wrote: post #156

Earlier quoted context omitted.

But we're talking about drastic differences in memory and CPU usage, not minor differences.

How does that have anything to do with my point? I said that Safari has an advantage over Chrome on Apple hardware only because it has an integration advantage. Chrome is still faster on most other platforms... including non-Google ones, like Windows and Linux - which the majority of users use. That is impressive. Meanwhile, there is nothing special about a browser that does best on hardware made by the same develope…

Chrome is definitely faster at using up all available resources! Platform-level optimization cannot lead to drastic changes in memory utilizations unless Google completely ignores the macOS platform! Which features are needed for the 99.99% browser usage? I open Chrome with 10 tabs opened and 15 minutes later it's using 8GB of RAM! Basic pages, like Messenger, Facebook, and Gmail. The same pages with the exact used browser features in Safari use just a fraction of the resources and actually provide a better browsing experience! So, Google should rethink what a browser is nowadays - from a thin client, they turned the browser into a morbidly-obese client!

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#159

Post by fouric »

nikolay wrote: post #158
fouric wrote: post #157

Earlier quoted context omitted.

How does that have anything to do with my point? I said that Safari has an advantage over Chrome on Apple hardware only because it has an integration advantage. Chrome is still faster on most other platforms... including non-Google ones, like Windows and Linux - which the majority of users use. That is impressive. Meanwhile, there is nothing special about a browser that does best on hardware made by the same develope…

Chrome is definitely faster at using up all available resources! Platform-level optimization cannot lead to drastic changes in memory utilizations unless Google completely ignores the macOS platform! Which features are needed for the 99.99% browser usage? I open Chrome with 10 tabs opened and 15 minutes later it's using 8GB of RAM! Basic pages, like Messenger, Facebook, and Gmail. The same pages with the exact used b…

> Basic pages, like Messenger, Facebook, and Gmail.

You belay your ignorance of webdev. Those three sites are all extremely heavy web applications - barely even "sites" - and I'm willing to bet you they still are faster on Chrome than on Safari (on non-Apple platforms).

> The same pages with the exact used browser features in Safari use just a fraction of the resources and actually provide a better browsing experience!

Instead of using your own subjective perception, you should try running a series of standard performance benchmarks, like the SunSpider JavaScript benchmarks[1] on Chrome and Safari on a non-Apple platform - then see if your perceived performance gap remains.

[1] https://webkit.org/perf/sunspider/sunspider.html

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#160

Post by nikolay »

fouric wrote: post #159
nikolay wrote: post #158

Earlier quoted context omitted.

Chrome is definitely faster at using up all available resources! Platform-level optimization cannot lead to drastic changes in memory utilizations unless Google completely ignores the macOS platform! Which features are needed for the 99.99% browser usage? I open Chrome with 10 tabs opened and 15 minutes later it's using 8GB of RAM! Basic pages, like Messenger, Facebook, and Gmail. The same pages with the exact used b…

> Basic pages, like Messenger, Facebook, and Gmail. You belay your ignorance of webdev. Those three sites are all extremely heavy web applications - barely even "sites" - and I'm willing to bet you they still are faster on Chrome than on Safari (on non-Apple platforms). > The same pages with the exact used browser features in Safari use just a fraction of the resources and actually provide a better browsing experienc…

Subjective, really? So, I open the same tabs in both browsers and I see the resource utilization difference and that's subjective? I don't care about the browser features, which make Chrome use all available resources on my computer in 10 minutes after launching!
Post reply on HN