4 ms·

Yes to your OpenCL stuff, no to your reverse-engineering stuff. The post you linked is about generating your own native shaders on GCN. GPUOpen could possibly

by robbies 11y ago

Yes to your OpenCL stuff, no to your reverse-engineering stuff. The post you linked is about generating your own native shaders on GCN. GPUOpen could possibly expose that, but that's a difficult problem to expose to developers considering the variety of architectures exposed at any time by the IHVs (including just inside one IHV at any time). If they did go down that path, they would open up their internal bytecode-to-native-ISA shader compiler...which they haven't done yet, and have shown no indication of doing.

wtallis 11y ago
Yes, it may be a difficult problem to handle exposing hardware-specific functionality in a non-portable way, but if GPUOpen is to have any substance at all it's obvious that they're going to actually do some of that. This can't just be an announcement of a batch of OpenGL vendor extensions. And at the moment, it seems like GPU architectures within one company aren't really that much more diverse than Intel's CPU architectures over a similar time period. They're not overhauling the ISA every year.
- robbies 11y ago
  > but if GPUOpen is to have any substance at all it's obvious that they're going to actually do some of that. I don't think they'll do it. I think they're going to shoot for SPIR-V being close enough that SPIR-V compilers generate code good enough that the internal compilers can gen good ISA code. > They're not overhauling the ISA every year. They aren't, but the changes rev to rev are more significant than you'd expect. On top of that, the big bumps are significant, such as Fermi to Kepler or Northern Islands to Southern Islands (or whatever). These are not backwards compatible with each other, unlike Intel x86 ISA. Bonus edit: Also...I'd speculate that some IHVs would rather not expose their IL-to-ISA compiler. Not because of 'secret sauce'. But because they aren't that good, and would rather have the OSS community start fresh and do a better job.

by robbies 11y ago

wtallis 11y ago

Yes, it may be a difficult problem to handle exposing hardware-specific functionality in a non-portable way, but if GPUOpen is to have any substance at all it's obvious that they're going to actually do some of that. This can't just be an announcement of a batch of OpenGL vendor extensions. And at the moment, it seems like GPU architectures within one company aren't really that much more diverse than Intel's CPU architectures over a similar time period. They're not overhauling the ISA every year.

robbies 11y ago
> but if GPUOpen is to have any substance at all it's obvious that they're going to actually do some of that. I don't think they'll do it. I think they're going to shoot for SPIR-V being close enough that SPIR-V compilers generate code good enough that the internal compilers can gen good ISA code. > They're not overhauling the ISA every year. They aren't, but the changes rev to rev are more significant than you'd expect. On top of that, the big bumps are significant, such as Fermi to Kepler or Northern Islands to Southern Islands (or whatever). These are not backwards compatible with each other, unlike Intel x86 ISA. Bonus edit: Also...I'd speculate that some IHVs would rather not expose their IL-to-ISA compiler. Not because of 'secret sauce'. But because they aren't that good, and would rather have the OSS community start fresh and do a better job.