Hacker News Reader

Comment by zozbot234 | Hacker News Reader

AIUI, Glide cards didn't really do 3d acceleration in anything like a modern sense. They accelerated the rasterization part of the rendering pipeline; they were basically very fast (for the time) 2D triangle renderers.

(Thus, reimplementing this under either OpenGL or Vulkan ought to be reasonably trivial using modern hardware.)

View on HN

If we're arguing semantics, I feel like these early cards are more fitting to the "3D accelerator" name than the modern ones. They were specialized for accelerating 3D graphics (which, in the end, means pushing triangles into a 2D framebuffer). Modern GPUs are more like general-purpose vector processors that happen to also be good at calculations related to 3D graphics and can (sometimes) render triangles to a framebuffer.

Being 2D rasterizers was arguably true for some cheap early graphics chips like that of the PS1. For Voodoos, there was no point in the pipeline after which rendering is “only 2D” in any relevant sense. At the time, the Z coordinate was passed to the hardware and used e.g. for important things like perspective correct texture lookup, environment maps (fake reflections), and Z buffering — that is right until the very last moment of committing the pixel to memory.

i'd argue that 3d-accelerated graphics from that era is still true 3d acceleration. of course, back then the pipelines were mostly fixed - nothing like programable shaders - but you're passing in 3d-coordinates, generating some matrices to determine the MVP, passing in some textures, and getting most of that "heavy lifting" of getting the pixels on the screen from the API & card.

> they were basically very fast (for the time) 2D triangle renderers.

that's still true of GPUs today :) in fact, with the exception of h264/265 encode/decode, and "AI" - that's all that graphics cards have ever done!

The point is that the 3D-geometry portion of the pipeline is still done on CPU with these early cards. The API's may have been slightly broader, but the hardware accelerated part was limited to rasterization, i.e. painting 2D triangles.

indeed, and i agree - what i'm saying is that even today, the rasterization of triangles is still 2D :) (and necessarily will always be! well, as long as we use 2D displays..)

The triangles are in 3D space. Part of what the cards do is project them into 2D space. See pp. 18-20 of the Glide reference: https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=18...

It explicitly states that vertices are given as (x, y). Voodoo cards did not do projection in hardware.

The GrVertex structure has z and w components too. But it’s a fair point that the x and y is specified in screen space, not world space. I had forgotten that. But the hardware does depth buffering based on the z component, so it’s still 3D.

Yeah, that's a nice "hack" the hardware offered. You can still shove in the depth after having done the screen projection so you don't need to worry about the order in which you draw the triangles. So maybe 2.5D? :-)

> rasterization, i.e. painting 2D triangles

As I explained in a sister comment, there's a lot more going on with rasterization, even back then, than "painting 2D triangles" might imply. Yes, only the XY coordinates determine the screen location of a rendered pixel, but the Z coordinate even at that stage has a lot to do with its color (e.g. for perspective-correct texture lookup) and whether it is painted at all (Z buffering).

The rendition GPU was a risc processors but alas way to early and underperforming

They also do texture mapping, shading, and z buffering. Those things are still the core of 3D rendering.

GLIDE was low level, it would map to Vulkan perfectly.

I’m sure it can be emulated efficiently enough nowadays, but I don’t think the mapping is very direct: Glide was mostly imperative and synchronous, Vulkan is declarative and explicitly asynchronous. Both are low-level, but for hardware that works very differently.

even 15 years ago, Glide wrappers (Glide to DirectX or OpenGl) did a great job

In terms of API design and usage Glide is far closer to classic 1.x GL.

I guess Glide could be defined as low-level API since it was defined by single vendor's architecture instead of some more abstract machine like GL and other APIs.

Reply on news.ycombinator.com