http://frguthmann.github.io
Why would anyone do this? I have been playing around with WebGPU recently, writing a toy engine in JS and running it on Chrome. The debugging situation is great now, PIX just works and I can usually identify and fix issues quickly when they arise. However, when it comes to profiling, well the situation is not that great. For instance, AMD’s Radeon Developer Panel will detect Chrome as a DX12 app (when using the proper flags), it will attach to the process and even let me start a capture.
Fast Forward If you’ve read the article already and/or want to jump straight to profiling, go to the TL;DR section. Context WebGPU is not a native graphics API, as in no hardware vendor provides specific drivers for their GPUs targeting this API. Instead, WebGPU runtimes like web browsers must implement backends for WebGPU using modern native APIs such as DirectX12, Vulkan or Metal. Those APIs are widely used, in particular for video games, and hardware vendors have developed great profiling tools for them.
Pleased to announce many more speakers for our conference here in Europe later this year: https://www.graphicsprogrammingconference.nl/
If you haven't read the whole list, go now, as I'm super happy that we'll have a Ghost of Tsushima post mortem (and many other great talks)!
If you have a talk idea, please do sign up now as the deadline is approaching fast! We need your talk to make this a success and show that Europe can do graphics!
@froyok I can relate to that. The only reason I know about it is because I was following closely when the changes were made. It's also super cheap and easy to integrate when someone ran the math for you :p.
TLDR: rough surfaces tend to be darker than they should be because masking and shadowing terms don't account for rays that escape the micro facets after a few bounces. A precomputed multiple scattering factor is stored in the LUT to compensate for that.