| ▲ | fooblaster 11 hours ago |
| Let's see if developers sleepwalk into another trap to keep us locked into nvidia's hardware for the next decade. |
|
| ▲ | pjmlp 3 hours ago | parent | next [-] |
| It is up to AMD, Intel and Khronos to offer APIs and tools that are actually nice to use. They have had about 15 years to move beyond C99, stone age workflows to compile GLSL and C99 with their drivers, no libraries ecosystem, and printf debugging. Eventually some of the issues have been fixed, after they started seeing only hardliners would put with such development experience, and then it was too late. |
| |
|
| ▲ | the__alchemist 9 hours ago | parent | prev | next [-] |
| IMO it's not Nvidia's fault the competing APIs are high friction. |
| |
| ▲ | flyingcoder 9 hours ago | parent [-] | | AMD screwed up so badly. | | |
| ▲ | fooblaster 9 hours ago | parent | next [-] | | That is true, but that doesn't mean Nvidia is not engaging in engineering to intentionally kneecap competition. Triton and other languages like that are a huge threat and CUtile is a means to combat that threat and prevent a hardware abstraction layer. | |
| ▲ | positron26 8 hours ago | parent | prev [-] | | Hundreds of thousands of developers with access to a global communication network were not stopped by AMD. Why act like dependents or wait for some bright star of consensus unless the intent is really about getting the work for free? We don't have to wait for singular companies or foundations to fix ecosystem problems. Only the means of coordination are needed. https://prizeforge.com isn't there yet, but it is already capable of bootstrapping its own development. Matching funds, joining the team, or contributing on MuTate will all make the ball pick up speed faster. | | |
| ▲ | nemothekid 27 minutes ago | parent [-] | | >We don't have to wait for singular companies or foundations to fix ecosystem problems. Geohot has been working on this for about a year, and every roadblock he's encountered he has had to damn near pester Lisa Su about getting drivers fixed. If you want the CUDA replacement that would work on AMD, you need to wait on AMD. If there is a bug in the AMD microcode, you are effectively "stopped by AMD". |
|
|
|
|
| ▲ | OneDeuxTriSeiGo 7 hours ago | parent | prev | next [-] |
| CUDA Tile is an open source MLIR Dialect so it wouldn't take much to write MLIR transforms to map it from the Tile IR to TOSA or gpu + vector + some amdgpu or other specialty dialects. The Tile dialect is pretty much independent of the nvidia ecosystem so all it takes is one good set of MLIR transform passes to run anything on the CUDA stack that compiles to tile out of the nvidia ecosystem prison. So if anything this is actually a massive opportunity to escape vendor lock in if it catches on in the CUDA ecosystem. |
| |
| ▲ | RobotToaster 2 hours ago | parent | next [-] | | Or it's Nvidia doing an Embrace Extend Extinguish on MLIR. | | | |
| ▲ | saagarjha 6 hours ago | parent | prev [-] | | Yes, but why would you want to use this over the other MLIR dialects that are already cross platform? |
|
|
| ▲ | trueismywork 7 hours ago | parent | prev | next [-] |
| TileIR is Apache licensed so AMD can implement it as well. |
|
| ▲ | RicoElectrico 2 hours ago | parent | prev [-] |
| Obviously they will, as with the mainframe and cloud. |
