5 ms·

I am not sure that it would work because it is unlikely that you can test your application with all existing videocards (and yet to be released cards). And even

I am not sure that it would work because it is unlikely that you can test your application with all existing videocards (and yet to be released cards). And even if you do that the performance might depend on other factors (OS, CPU model, RAM type and size, driver version). Instead game developers should provide an option to select graphic settings: more textures, less textures, more shaders, less shaders and so on, and display a FPS counter so that the user is able to decide what is better for them. Or automatically switch to lower settings if fps falls below cetrain threshold.

moron4hire 4y ago
It's not just about performance. There are bugs in certain GPUs and drivers that can crash the browser or even produce fundamentally wrong results. It's not just "scale graphics quality", in some cases specific work-arounds with completely different semantics are needed.
- midislack 4y ago
  Like which ones?
  - moron4hire 4y ago
    One particular one I've struggled with only appears on macOS with Intel Iris Xe GPUs in which the texture sampling in my default, high-performance, seamless skybox renderer bugs out and only makes one face of the cube render correctly. I have to fall back to physical geometry to fix it, which is not as efficient, causes ugly seams at the edges of the cube, and also overcomplicates handling transparent images and image alignment if I'm not very, very careful. And my app isn't even all that complex. There are so many bugs to handle, but luckily Three.js handles the vast majority of them for me. You can't count on even very basic apps to be completely compatible across all devices.
  - shadowgovt 4y ago
    I encountered problems on an Intel card config once where a simple multiplication of three values in the shader resulted in 0 being emitted due to a bug in the shader compiler itself. Workaround was to wrap the whole equation in a multiplication by 1.00000000001, which (we assume, closed source architecture that's very difficult to crack the black box on) forced the compiler to stop trying to use an optimization that was dropping our values on the floor.
    - codedokode 4y ago
      This bug presense can be tested without knowing the GPU model.
      - shadowgovt 4y ago
        It's tested far faster with a card list. But you're right, in practice a lot of engines do both... They render a known image at boot-up and check it for consistency. But once you know you have a problem, you don't know how to solve it, so you might as well query the card anyway.
      - robocat 4y ago
        > This bug presense can be tested without knowing the GPU model Testing for bugs is fingerprinting - you are back at square zero.
        account42 4y ago
        And the bug should be fixed in the driver, yes. Still no reason to provide the fingerprinting info for free for all cards and vendors.
        shadowgovt 4y ago
        > And the bug should be fixed in the driver, yes. But that's the problem. The developer has no power to make that happen. Between vendors failing to support their chips once they released to the public and users failing to upgrade their machines... Some of the Intel bugs are over a decade old. This is one of those network effect problems not unlike the question of whether a website is broken if it doesn't work under Firefox. If a game doesn't work on a user's computer, the game is broken, not the computer. This whole conversation has raised an interesting point, because bugs like that will never be fixed in the driver. And similarly, different versions of web browsers have different quirks and bugs in their implementations. I suspect you could build quite a fingerprinting profile by tickling those bugs and quirks... Not just in the webgl implementation, but in the DOM implementation, etc.
lillecarl 4y ago
You might not be able to test every possible card, but game engines that target browsers might have that capacity.
coldpie 4y ago
Like sibling comments say, this behavior is really common, trying to tell people to stop doing it just isn't going to happen. If you really want to get your blood boiling, Vulkan since day 1 has had an application info struct which gets passed down to drivers, so drivers can work around application bugs and optimize for their specific loads! https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VkApplicationInfo.html https://www.khronos.org/registry/vulkan/specs/1.3-extensions...

moron4hire 4y ago

It's not just about performance. There are bugs in certain GPUs and drivers that can crash the browser or even produce fundamentally wrong results. It's not just "scale graphics quality", in some cases specific work-arounds with completely different semantics are needed.

midislack 4y ago
Like which ones?
- moron4hire 4y ago
  One particular one I've struggled with only appears on macOS with Intel Iris Xe GPUs in which the texture sampling in my default, high-performance, seamless skybox renderer bugs out and only makes one face of the cube render correctly. I have to fall back to physical geometry to fix it, which is not as efficient, causes ugly seams at the edges of the cube, and also overcomplicates handling transparent images and image alignment if I'm not very, very careful. And my app isn't even all that complex. There are so many bugs to handle, but luckily Three.js handles the vast majority of them for me. You can't count on even very basic apps to be completely compatible across all devices.
- shadowgovt 4y ago
  I encountered problems on an Intel card config once where a simple multiplication of three values in the shader resulted in 0 being emitted due to a bug in the shader compiler itself. Workaround was to wrap the whole equation in a multiplication by 1.00000000001, which (we assume, closed source architecture that's very difficult to crack the black box on) forced the compiler to stop trying to use an optimization that was dropping our values on the floor.
  - codedokode 4y ago
    This bug presense can be tested without knowing the GPU model.
    - shadowgovt 4y ago
      It's tested far faster with a card list. But you're right, in practice a lot of engines do both... They render a known image at boot-up and check it for consistency. But once you know you have a problem, you don't know how to solve it, so you might as well query the card anyway.
    - robocat 4y ago
      > This bug presense can be tested without knowing the GPU model Testing for bugs is fingerprinting - you are back at square zero.
      - account42 4y ago
        And the bug should be fixed in the driver, yes. Still no reason to provide the fingerprinting info for free for all cards and vendors.
        shadowgovt 4y ago
        > And the bug should be fixed in the driver, yes. But that's the problem. The developer has no power to make that happen. Between vendors failing to support their chips once they released to the public and users failing to upgrade their machines... Some of the Intel bugs are over a decade old. This is one of those network effect problems not unlike the question of whether a website is broken if it doesn't work under Firefox. If a game doesn't work on a user's computer, the game is broken, not the computer. This whole conversation has raised an interesting point, because bugs like that will never be fixed in the driver. And similarly, different versions of web browsers have different quirks and bugs in their implementations. I suspect you could build quite a fingerprinting profile by tickling those bugs and quirks... Not just in the webgl implementation, but in the DOM implementation, etc.

lillecarl 4y ago

You might not be able to test every possible card, but game engines that target browsers might have that capacity.

coldpie 4y ago

Like sibling comments say, this behavior is really common, trying to tell people to stop doing it just isn't going to happen. If you really want to get your blood boiling, Vulkan since day 1 has had an application info struct which gets passed down to drivers, so drivers can work around application bugs and optimize for their specific loads! https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VkApplicationInfo.html https://www.khronos.org/registry/vulkan/specs/1.3-extensions...