5 ms·

There was an article back in March wherein a Stack Overflow (or Quora?) user comment about the hilariously porous boundary between game engines, drivers and act

by chao- 11y ago

There was an article back in March wherein a Stack Overflow (or Quora?) user comment about the hilariously porous boundary between game engines, drivers and actual hardware on GPUs. I'll see if I can find it because as much as I love a good ole shitshow of industry skulduggery, I can completely see a best-intentions effort leading to these sorts of unintended consequences (doing their best to get tessellation working, and so forth). Disclaimer of non-fanboy-ism: I don't play video games anymore, and only have graphics via Intel on my machine. No stock in Nvidia or AMD either. Edit: Found it, and my memory completely sucks. It was an article on gamedev.net about lower-level graphics APIs: http://www.gamedev.net/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/#entry5215019 http://www.gamedev.net/topic/666419-what-are-your-opinions-o...

nextw33k 11y ago
I remember reading that link and thinking about how the standards are not working. It also concerns me for the future of the open source graphics stack. If the proprietary drivers are being updated to fix game specific problems, how are the open source drivers going to fair when the general rule for open source is not to have hacks within a code base. I can only hope that the Mesa 3D stack comes to Windows in a meaningful way to ensure a common open 3D graphics library. Vulcan might shift the problem to the game engine from the driver but that's a long way off yet.
- lsadam0 11y ago
  > . If the proprietary drivers are being updated to fix game specific problems, how are the open source drivers going to fair when the general rule for open source is not to have hacks within a code base. I'm an outsider, so it's easy for me to sit back and make blanket statements. That being said, the responsibility should lie on game developers to insure their games behave properly on hardware. Making proprietary drivers to address specific games is a bad development practice. Hardware markers should be responsible for insuring their drivers are accurately supporting standards. It just sounds like the whole games industry has fallen into some really bad development practices.
  - chao- 11y ago
    The thing is, as referenced in the article I linked, there is a blurred line in functionality between what the GPU can do, via what the driver exposes, and what the GPU can do, if only they would write something for you to help massage it a bit and enable in the way you need. Without access to the engineer's knowledge of the GPU's hardware, it's hard for the open source developers to even know what they ought to be able to implement. It follows that game studios (and consumers) would be crazy to rely on the coin-flip-odds that an open source implementation will figure out the right thing to do for a particular optimization of the GPU's internals I am also an outsider, but have had a few friends work on various graphics projects (game engines, CAD software, one of them use to have a map of the OpenGL state machine above his bed). To hear them tell it, trying to maintain absolute "best practices" and only use truly cross-platform, cross-vendor code in your libraries while still hitting deadlines for games is like the mythical web startup that somehow ships despite also investing time in 100% unit test coverage, 100% integration tests, with a little bit of mutation testing and generative testing on top to help test-drive the test suite. That is: it's more of an ideal to strive for than a reality to be lived. As a Linux user I weep at this state of affairs, but given the way GPUs are made, I don't know what could change.
- digi_owl 11y ago
  > the general rule for open source is not to have hacks within a code base. The Linux kernel devs must have missed a memo then, as they seem quite willing to accept "hacks" if it means that user space can continue running. The user space middleware seem more willing to blame other tiers when something breaks though.

by chao- 11y ago

nextw33k 11y ago

I remember reading that link and thinking about how the standards are not working. It also concerns me for the future of the open source graphics stack. If the proprietary drivers are being updated to fix game specific problems, how are the open source drivers going to fair when the general rule for open source is not to have hacks within a code base. I can only hope that the Mesa 3D stack comes to Windows in a meaningful way to ensure a common open 3D graphics library. Vulcan might shift the problem to the game engine from the driver but that's a long way off yet.

lsadam0 11y ago
> . If the proprietary drivers are being updated to fix game specific problems, how are the open source drivers going to fair when the general rule for open source is not to have hacks within a code base. I'm an outsider, so it's easy for me to sit back and make blanket statements. That being said, the responsibility should lie on game developers to insure their games behave properly on hardware. Making proprietary drivers to address specific games is a bad development practice. Hardware markers should be responsible for insuring their drivers are accurately supporting standards. It just sounds like the whole games industry has fallen into some really bad development practices.
- chao- 11y ago
  The thing is, as referenced in the article I linked, there is a blurred line in functionality between what the GPU can do, via what the driver exposes, and what the GPU can do, if only they would write something for you to help massage it a bit and enable in the way you need. Without access to the engineer's knowledge of the GPU's hardware, it's hard for the open source developers to even know what they ought to be able to implement. It follows that game studios (and consumers) would be crazy to rely on the coin-flip-odds that an open source implementation will figure out the right thing to do for a particular optimization of the GPU's internals I am also an outsider, but have had a few friends work on various graphics projects (game engines, CAD software, one of them use to have a map of the OpenGL state machine above his bed). To hear them tell it, trying to maintain absolute "best practices" and only use truly cross-platform, cross-vendor code in your libraries while still hitting deadlines for games is like the mythical web startup that somehow ships despite also investing time in 100% unit test coverage, 100% integration tests, with a little bit of mutation testing and generative testing on top to help test-drive the test suite. That is: it's more of an ideal to strive for than a reality to be lived. As a Linux user I weep at this state of affairs, but given the way GPUs are made, I don't know what could change.
digi_owl 11y ago
> the general rule for open source is not to have hacks within a code base. The Linux kernel devs must have missed a memo then, as they seem quite willing to accept "hacks" if it means that user space can continue running. The user space middleware seem more willing to blame other tiers when something breaks though.