Hacker News Reader

Comment by fendrak | Hacker News Reader

In an ideal future, we'd have something like x86, but for graphics hardware. Standardizing the assembly language would go a long ways towards encouraging good compiler design and third-party libraries for rendering.

View on HN

Strongly disagree - the fact that GPU ISA is undocumented let GPU vendors to innovate faster, and let them modify ISA not only between models, but also inside the same architecture family.

For NVIDIA only documented PTX, while actual ISA is changed frequently. Same with AMD: CAL is documented, but the actual low-level ISA can change. For example recently they moved from VLIW5 to VLIW4.

I also think, that reliance on hard ISA (x86 or ARM) in modern server-desktop-mobile world is doing more harm, than good.

Today there are just too many layers/levels, for example in NVIDIA:

  CUDA -> LLVM -> PTX -> native ISA
  CUDA -> LLVM -> x86 -> Intel Microcode
  OpenCL -> CUDA -> LLVM -> PTX -> native ISA
  OpenCL -> CUDA -> LLVM -> x86 -> Intel Microcode

or in AMD:

  OpenCL -> LLVM -> CAL -> native ISA
  OpenCL -> LLVM -> x86 -> AMD Microcode

The C was that kind of universal ISA in the RISC UNIX world. But C can't express Vectorization and SIMD efficiently and in platform independent way. Enter OpenCL!

Strongly agree =). Once I was coding assembly and I thought I might be able to avoid operating-system-specific graphic APIs by going through openGL.

Unfortunately, both openGL and DirectX are C libraries. A graphics driver is just a C library translating openGL api to your cards undocumented internals. As a result, you talk with C calling conventions and C data structures (which are a chore without a C compilers help).

This shouldn't limit innovation. It is just specifying the calling convention and structures (and choosing ones that are easy in ASM). A C library would then sit on top of the ASM one, which is the natural order of things =).

I strongly disagree. Enforcing an ISA would prevent a lot of the technological advances in graphics card design.

I think unifying the assembly language would be quite difficult given the large churn in the underlying hardware architectures as the GPUs evolve. DirectX is mostly fine, and it has served well to allow games to continue to operate even when they were developed against much older versions of the API.

Perhaps more work can be done driver side. For example, allow developers to hint at the formats of data used so the driver doesn't always have to check degenerate conditions, like textures of a certain size or mismatches in vertex shader outputs and pixel shader inputs. Maybe the old capabilities model of DX9 would allow the option of a faster path.

That future might be happening already. Both AMD and Intel have products that pair CPU with GPU, ARM has Mali, NVidia's Tegra has on-chip GPU.

I think discrete GPUs will become niche products in the future. Once mainstream GPUs are on-chip, the variety of different GPU architectures will probably be reduced. The next step might be a standard ISA for GPU.

It is hard to say where GPUs will be in three years, but at least the industry is getting interesting again. It has been more of the same for so many years in discrete GPUs, but now the on-chip GPUs are potentially game changing.

Even though your vision is probably right, I'm not entirely happy with it. I love choice, I love being able to choose a certain processor and GPU and upgrading one of them after a year.

I'm probably the minority though, so business wise it makes sense.

The future will be a framebuffer. We're moving to a GPU-on-core future. The graphics card simply becomes a framebuffer at that point - ala video cards from the 80's and 90's.

So the likely future? x86+gpu extensions or arm+gpu extensions.

Reply on news.ycombinator.com