4 ms·

The whole thing sounds insanely complicated, and unclear that the complexity could ever be hidden behind a standard OpenGL-like 3D API.

by blt 7y ago

mathgladiator 7y ago
It may have made more sense back then, and maybe there was a belief that the complexity was worth it to push a new standard like API. Innovation is hard, and it's worth respecting all attempts.
goatinaboat 7y ago
Consider that this work started in 1991 and OpenGL wasn’t a thing outside of SGI until 1992.
- pjmlp 7y ago
  Consider that we were already doing GPGPU like programming (in concept at least) on the Amiga with DMA and Agnus in 1987. https://en.wikipedia.org/wiki/MOS_Technology_Agnus https://en.wikipedia.org/wiki/MOS_Technology_Agnus And before miniGL came to be, we already had Glide on the PC. https://en.wikipedia.org/wiki/Glide_(API) https://en.wikipedia.org/wiki/Glide_(API) Had it not been for miniGL and Carmacks advocacy for OpenGL, it wouldn't have been much of a thing outside SGI.
  - goatinaboat 7y ago
    I still have my Amiga! SGI started with their proprietary IrisGL and that became OpenGL at the behest of other Unix vendors at the time.
    - pjmlp 7y ago
      OpenGL would have been better if that role had been taken by Iris Inventor.[0] Instead it became a rite of passage for every OpenGL beginner to reimplement Inventor on their own way, either from scratch or playing Tetris with different kinds of libraries. Meanwhile, other graphical SDKs always provided such APIs. By the way, the best 3D API back then was Renderman, the genesis for modern shading languages. https://www.amazon.com/RenderMan-Companion-Programmers-Realistic-Computer/dp/0201508680 https://www.amazon.com/RenderMan-Companion-Programmers-Reali... [0] Yes there was Open Inventor afterwards, but its story is a bit convoluted.
jandrese 7y ago
The point where it all falls apart if the application falls behind for one frame is a showstopper for game development.
- goatinaboat 7y ago
  It used to be the norm in game development to sync with the refresh rate of the CRT.
  - CamperBob2 7y ago
    But at least you had a frame buffer to handle those few cases in any given game where you weren't quite fast enough, or where the OS goes out to lunch briefly. Talisman was a pretty goofy idea in retrospect (and seemed goofy to me at the time as well.) Completely non-scalable. It was an exercise in optimizing things that were already fast, which is the last thing you want to do in game development where you're going to be judged on your slowest frames.
  - deathanatos 7y ago
    Is it not still the norm? (Though, with an LCD screen of course, not with a CRT.) Many of my games include some form of vsync option, I think. (E.g., Factorio calls it "Wait for VSync", 7 Days to Die "VSync", Zandronum (a modern Doom port) "Vertical Sync"). My understanding was that it was a trade-off between smooth graphics at the display's framerate, or a faster framerate with potential tearing (on-screen artifact). With it off, you'll "see" something as soon as the currently rendering frame renders a pixel containing whatever is relevant. But with Vsync on, you'd need to wait until the next frame renders (and for it to hit a relevant pixel), introducing a slight delay, and tearing when the new frame overwrites the old frame at the point where the display is currently "drawing"/displaying. (Though it does seem like it is defaulted to "off". It's my understanding the pro gamers like the lower latency over the visual artifacting.)
    - aidenn0 7y ago
      This is not the norm; wait for vsync means the frame will be displayed during the vblank; if it takes you 6 frames to draw, then you have a frozen image for 6 frames. GP was talking about rendering each frame in lockstep with the vertical refresh; there is no option to wait, you will instead get a partially drawn frame (TFA mentions the runway disappearing in flightsims; that's a common artifact because much of the geometric complexity was on the ground, so when you are landing, the complexity would spike, the engine would lag behind and some things just wouldn't get drawn in time).
Const-me 7y ago
Modern GPUs do way more magic under the hood. BTW, that talisman uses tiled rendering strategy that's now implemented in many modern GPUs: https://en.wikipedia.org/wiki/Tiled_rendering https://en.wikipedia.org/wiki/Tiled_rendering Also modern 3D APIs, Metal, DX12, Vulkan, are very OpenGL-unlike. They don't hide much complexity, they embrace and expose it.
- phire 7y ago
  What was insane about talisman is that it tried to render the tiles "just in time" Other tiled renders (both powervr at the time and all modern mobile GPUs) would write the color tile back to an in-memory color buffer and scan out the image to screen from that. They also had fall-back paths if a game does something that can't be expressed in a pure tiled way (like many post-processing effects). They would flush both the tile color and tile depth out to in-memory color and depth buffers buffers and then pull those back in to restart tiles later. Nvidia's Maxwell and later desktop GPUs take this to the extreme and flush those tiles in-and-out so many times per frame. Telisman doesn't (can't?) do this. It tried to render all the tiles it needs for scanning out the next 32 lines into a small on-chip buffer and scan those out while rendering the next set of tiles for the next 32 lines. This saves on memory bandwidth but the whole approach falls apart if you try to render too many polygons. Instead of frames being late, parts of the screen disappear.
  - mntmoss 7y ago
    Yes, and this kind of issue comes up a lot in computing when trying to find deep optimizations: If you make a processing pipeline that drops information and reduces quality as it goes along, you can always turn that into a speed-up, but some features become hard and others become impossible. So in the end most pipelines cohere into an unexciting but generalized-enough solution that retains some extra data, while the cool hacks and approximations are left as special cases used to get an effect in specific applications(and the history of real-time 3D is, in essence, a history of progressively fewer cool hacks and more generalizations).

The whole thing sounds insanely complicated, and unclear that the complexity could ever be hidden behind a standard OpenGL-like 3D API.

by blt 7y ago

The whole thing sounds insanely complicated, and unclear that the complexity could ever be hidden behind a standard OpenGL-like 3D API.

mathgladiator 7y ago

It may have made more sense back then, and maybe there was a belief that the complexity was worth it to push a new standard like API. Innovation is hard, and it's worth respecting all attempts.

goatinaboat 7y ago

Consider that this work started in 1991 and OpenGL wasn’t a thing outside of SGI until 1992.

pjmlp 7y ago
Consider that we were already doing GPGPU like programming (in concept at least) on the Amiga with DMA and Agnus in 1987. https://en.wikipedia.org/wiki/MOS_Technology_Agnus https://en.wikipedia.org/wiki/MOS_Technology_Agnus And before miniGL came to be, we already had Glide on the PC. https://en.wikipedia.org/wiki/Glide_(API) https://en.wikipedia.org/wiki/Glide_(API) Had it not been for miniGL and Carmacks advocacy for OpenGL, it wouldn't have been much of a thing outside SGI.
- goatinaboat 7y ago
  I still have my Amiga! SGI started with their proprietary IrisGL and that became OpenGL at the behest of other Unix vendors at the time.
  - pjmlp 7y ago
    OpenGL would have been better if that role had been taken by Iris Inventor.[0] Instead it became a rite of passage for every OpenGL beginner to reimplement Inventor on their own way, either from scratch or playing Tetris with different kinds of libraries. Meanwhile, other graphical SDKs always provided such APIs. By the way, the best 3D API back then was Renderman, the genesis for modern shading languages. https://www.amazon.com/RenderMan-Companion-Programmers-Realistic-Computer/dp/0201508680 https://www.amazon.com/RenderMan-Companion-Programmers-Reali... [0] Yes there was Open Inventor afterwards, but its story is a bit convoluted.

jandrese 7y ago

The point where it all falls apart if the application falls behind for one frame is a showstopper for game development.

goatinaboat 7y ago
It used to be the norm in game development to sync with the refresh rate of the CRT.
- CamperBob2 7y ago
  But at least you had a frame buffer to handle those few cases in any given game where you weren't quite fast enough, or where the OS goes out to lunch briefly. Talisman was a pretty goofy idea in retrospect (and seemed goofy to me at the time as well.) Completely non-scalable. It was an exercise in optimizing things that were already fast, which is the last thing you want to do in game development where you're going to be judged on your slowest frames.
- deathanatos 7y ago
  Is it not still the norm? (Though, with an LCD screen of course, not with a CRT.) Many of my games include some form of vsync option, I think. (E.g., Factorio calls it "Wait for VSync", 7 Days to Die "VSync", Zandronum (a modern Doom port) "Vertical Sync"). My understanding was that it was a trade-off between smooth graphics at the display's framerate, or a faster framerate with potential tearing (on-screen artifact). With it off, you'll "see" something as soon as the currently rendering frame renders a pixel containing whatever is relevant. But with Vsync on, you'd need to wait until the next frame renders (and for it to hit a relevant pixel), introducing a slight delay, and tearing when the new frame overwrites the old frame at the point where the display is currently "drawing"/displaying. (Though it does seem like it is defaulted to "off". It's my understanding the pro gamers like the lower latency over the visual artifacting.)
  - aidenn0 7y ago
    This is not the norm; wait for vsync means the frame will be displayed during the vblank; if it takes you 6 frames to draw, then you have a frozen image for 6 frames. GP was talking about rendering each frame in lockstep with the vertical refresh; there is no option to wait, you will instead get a partially drawn frame (TFA mentions the runway disappearing in flightsims; that's a common artifact because much of the geometric complexity was on the ground, so when you are landing, the complexity would spike, the engine would lag behind and some things just wouldn't get drawn in time).

Const-me 7y ago

Modern GPUs do way more magic under the hood. BTW, that talisman uses tiled rendering strategy that's now implemented in many modern GPUs: https://en.wikipedia.org/wiki/Tiled_rendering https://en.wikipedia.org/wiki/Tiled_rendering Also modern 3D APIs, Metal, DX12, Vulkan, are very OpenGL-unlike. They don't hide much complexity, they embrace and expose it.

phire 7y ago
What was insane about talisman is that it tried to render the tiles "just in time" Other tiled renders (both powervr at the time and all modern mobile GPUs) would write the color tile back to an in-memory color buffer and scan out the image to screen from that. They also had fall-back paths if a game does something that can't be expressed in a pure tiled way (like many post-processing effects). They would flush both the tile color and tile depth out to in-memory color and depth buffers buffers and then pull those back in to restart tiles later. Nvidia's Maxwell and later desktop GPUs take this to the extreme and flush those tiles in-and-out so many times per frame. Telisman doesn't (can't?) do this. It tried to render all the tiles it needs for scanning out the next 32 lines into a small on-chip buffer and scan those out while rendering the next set of tiles for the next 32 lines. This saves on memory bandwidth but the whole approach falls apart if you try to render too many polygons. Instead of frames being late, parts of the screen disappear.
- mntmoss 7y ago
  Yes, and this kind of issue comes up a lot in computing when trying to find deep optimizations: If you make a processing pipeline that drops information and reduces quality as it goes along, you can always turn that into a speed-up, but some features become hard and others become impossible. So in the end most pipelines cohere into an unexciting but generalized-enough solution that retains some extra data, while the cool hacks and approximations are left as special cases used to get an effect in specific applications(and the history of real-time 3D is, in essence, a history of progressively fewer cool hacks and more generalizations).