4 ms·

Good luck showing that when all graphics code is designed to be run on CPUs, nobody has spent more than trivial effort making GPU-compatible graphics algorithms

Good luck showing that when all graphics code is designed to be run on CPUs, nobody has spent more than trivial effort making GPU-compatible graphics algorithms, you can't afford new nodes, your GPU is first-generation (and so far from optimal), you can only use CPU memories (who would invent HBM if GPUs didn't exist?), you can only do fixed-function logic efficiently, you have no demos that don't look like programmer art, and you have no way of getting past the adoption hurdle. Even realtime RT, which is mostly just a compatible add-on to raster, only managed to get off the ground when NVIDIA decided to go all-in and tank the criticism for a generation by effectively forcing it on the customer. No other company could have done that, even though Imagination was pushing for RT hardware for ages before NVIDIA. > Do you follow the 'Mill' architecture? Yes. https://medium.com/@veedrac/to-reinvent-the-processor-671139a4a034 https://medium.com/@veedrac/to-reinvent-the-processor-671139...

gpderetta 6y ago
To be constructive, I do believe there is a future beyond classic OoO, but dynamic scheduling is going to be part of it, although possibly not of instructions but of BBs or even microthreads. The papers you referencing are quire interesting as they validate some ideas I was idly thinking about. I still would call these designs OoO though, just extended. The problem is that building a CPU is very expensive and high risk, going even a bit beyond the classic OoO can bankrupt you. Intel tried with Itanic and AMD almost ate its lunch; AMD tried with buldozer and shared execution units and almost collapsed; SUN tried with flock of chickens and is no more; Nvidia tried with denver, and well, I guess they had a lot of cash. Both AMD and Apple just made completely orthodox designs and were complete successes. Evolution is going to be in small steps, unless a new design can prove to be 10x better than the existing ones which is very unlikely.
- Veedrac 6y ago
  > I do believe there is a future beyond classic OoO, but dynamic scheduling is going to be part of it, although possibly not of instructions but of BBs or even microthreads. I agree, I find it hard to see how you could abandon dynamic scheduling without unreasonable sacrifices. My point isn't to say otherwise, just that we see less innovation than we would otherwise were our ecosystem built to handle it. GPUs have benefited hugely from the ability to rapidly change the ISA and a lot of internal details between each generation, and for each competitor to have their own take and extensions (Apple even has its own API, to support its TBDR features). If we had that sort of freedom in CPUs, I'm sure we'd have something a lot better than four variants of practically-the-same-thing by four different companies.
- brandmeyer 6y ago
  > Nvidia tried with denver, and well, I guess they had a lot of cash More likely: They recognized the failure and cut the program before losing too much money.
  - gpderetta 6y ago
    True, also Denver wasn't bad, just not good enough.
    - my123 6y ago
      Denver was superseded by the Carmel architecture. (which is sold on Tegra Xavier today) The NVIDIA CPU team is alive and well.
      - brandmeyer 6y ago
        There's a big difference between cancelling a project and firing the team. I haven't seen any evidence that Carmel utilizes binary translation.
cpgxiii 6y ago
The reality is that the embarrassingly parallel nature of graphics has been long understood, as well as the advantages of having graphics be handled by a different, dedicated processor (see Intel's i860 in the early 1990s). Unless in some alternate universe frequency scaling and memory bandwidth were never an issue, you're always going to come back to the reality that a parallel processor optimized for minimally-branchy math will be more efficient at graphics tasks. The early days of fixed-function hardware are, if anything, an aberration.
- Veedrac 6y ago
  And yet most non-games graphics workloads in industry were CPU rendered until 2010ish, I think. The draw of defaults is extremely strong.
  - cpgxiii 6y ago
    No. Back to the very first graphical workstations, people have people putting dedicated processors in computers for graphics (ex Apollo Computer using the TMS320 DSP for graphics math). The entire reason for legacy decisions in OpenGL is from non-gaming users, namely CAD vendors, who have been doing this for a long time.
    - Veedrac 6y ago
      The context is very different if you're talking about the early 1980s. I recognize (and have said before in this thread) that my arguments about lock-in don't apply to then.
pjmlp 6y ago
And the benefit is that now you have companies like OTOY doing basically CUDA based real time rendering.

gpderetta 6y ago

To be constructive, I do believe there is a future beyond classic OoO, but dynamic scheduling is going to be part of it, although possibly not of instructions but of BBs or even microthreads. The papers you referencing are quire interesting as they validate some ideas I was idly thinking about. I still would call these designs OoO though, just extended. The problem is that building a CPU is very expensive and high risk, going even a bit beyond the classic OoO can bankrupt you. Intel tried with Itanic and AMD almost ate its lunch; AMD tried with buldozer and shared execution units and almost collapsed; SUN tried with flock of chickens and is no more; Nvidia tried with denver, and well, I guess they had a lot of cash. Both AMD and Apple just made completely orthodox designs and were complete successes. Evolution is going to be in small steps, unless a new design can prove to be 10x better than the existing ones which is very unlikely.

Veedrac 6y ago
> I do believe there is a future beyond classic OoO, but dynamic scheduling is going to be part of it, although possibly not of instructions but of BBs or even microthreads. I agree, I find it hard to see how you could abandon dynamic scheduling without unreasonable sacrifices. My point isn't to say otherwise, just that we see less innovation than we would otherwise were our ecosystem built to handle it. GPUs have benefited hugely from the ability to rapidly change the ISA and a lot of internal details between each generation, and for each competitor to have their own take and extensions (Apple even has its own API, to support its TBDR features). If we had that sort of freedom in CPUs, I'm sure we'd have something a lot better than four variants of practically-the-same-thing by four different companies.
brandmeyer 6y ago
> Nvidia tried with denver, and well, I guess they had a lot of cash More likely: They recognized the failure and cut the program before losing too much money.
- gpderetta 6y ago
  True, also Denver wasn't bad, just not good enough.
  - my123 6y ago
    Denver was superseded by the Carmel architecture. (which is sold on Tegra Xavier today) The NVIDIA CPU team is alive and well.
    - brandmeyer 6y ago
      There's a big difference between cancelling a project and firing the team. I haven't seen any evidence that Carmel utilizes binary translation.

cpgxiii 6y ago

The reality is that the embarrassingly parallel nature of graphics has been long understood, as well as the advantages of having graphics be handled by a different, dedicated processor (see Intel's i860 in the early 1990s). Unless in some alternate universe frequency scaling and memory bandwidth were never an issue, you're always going to come back to the reality that a parallel processor optimized for minimally-branchy math will be more efficient at graphics tasks. The early days of fixed-function hardware are, if anything, an aberration.

Veedrac 6y ago
And yet most non-games graphics workloads in industry were CPU rendered until 2010ish, I think. The draw of defaults is extremely strong.
- cpgxiii 6y ago
  No. Back to the very first graphical workstations, people have people putting dedicated processors in computers for graphics (ex Apollo Computer using the TMS320 DSP for graphics math). The entire reason for legacy decisions in OpenGL is from non-gaming users, namely CAD vendors, who have been doing this for a long time.
  - Veedrac 6y ago
    The context is very different if you're talking about the early 1980s. I recognize (and have said before in this thread) that my arguments about lock-in don't apply to then.

pjmlp 6y ago

And the benefit is that now you have companies like OTOY doing basically CUDA based real time rendering.