Why was glide faster than opengl / direct3d?

[Commenter]

I just wondered why a proprietary api like Glide was able to achieve faster rendering on 3dfx's hardware of the day than an open api like d3d and opengl?

 

[BRiT]

CTM: closer to the metal.

 

[Colourless]

Glide also didn't need to do calls into the kernel to perform operations which is a massive performance increase compared to d3d.

 

[swaaye]

D3D was also total garbage until version 5 or 6.

OpenGL wasn't well suited to simple 90s GPUs meant for games.

 

[Pixel]

Aren't you also talking about a time where 3d rendering was more cpu bound. Didn't the old 3d accelerator cards take less workload off the cpu compared to cards now days? Thus this is another reason the api weighing down the cpu became less and less of a factor?

 

[Exophase]

Aren't you also talking about a time where 3d rendering was more cpu bound. Didn't the old 3d accelerator cards take less workload off the cpu compared to cards now days? Thus this is another reason the api weighing down the cpu became less and less of a factor?

Yes, and the CPUs didn't have underutilized additional hardware threads to soak up some of the API overhead.

The overhead for legacy OpenGL's direct mode was really egregious. At least one if not multiple function calls per vertex and having to evaluate state for each one. I bet the overhead was on a similar level to the software T&L itself. I have to seriously wonder what they were thinking.

 

[swaaye]

If you wanted your K6 based CPU to be more tolerable, you certainly wanted Glide instead of D3D or OpenGL. Voodoo cards also tended to be the only cards that worked right on non-Intel AGP implementations of the time.

Also, Voodoo Rush was the first 3dfx product with hardware triangle setup. Voodoo1 was thus extra CPU dependent. This was a point that Rendition drove home against Voodoo1 because even V1000 did triangle setup, and was also DMA driven so more efficient.

 

[Davros]

also there were 3d-now patches available mainly for games that used 3dfx's minigl

 

[backgroundpersona]

GLide was better than Open GL and DirectX because it was "closer to the metal" because there was less code to be used and was a slimmed down Open GL API for games thus less code was needed for same result since it would take less time to find the necessary code for execution.

Also GLide is exclusive API for 3DFX cards thus it used the hardware of these cards more efficiently, it was something akin of what Mantle was today in a way. An exclusive API for the GPU.

 

[UniversalTruth]

GLide was better than Open GL and DirectX because it was "closer to the metal" because there was less code to be used and was a slimmed down Open GL API for games thus less code was needed for same result since it would take less time to find the necessary code for execution.

Also GLide is exclusive API for 3DFX cards thus it used the hardware of these cards more efficiently, it was something akin of what Mantle was today in a way. An exclusive API for the GPU.

oki doki, why doesn't NVidia introduce something like GLide in order to combat Mantle?

 

[sebbbi]

oki doki, why doesn't NVidia introduce something like GLide in order to combat Mantle?

Nvidia has OpenGL extensions (such as bindless resources, multidraw and custom resource management) that provide similar performance boosts than Mantle. Sometimes Mantle is better, but for engines that are designed to abuse Nvidia bindless multidraw, it certainly beats Mantle in pure draw call count.

 

[linthat22]

Nvidia has OpenGL extensions (such as bindless resources, multidraw and custom resource management) that provide similar performance boosts than Mantle. Sometimes Mantle is better, but for engines that are designed to abuse Nvidia bindless multidraw, it certainly beats Mantle in pure draw call count.

So would you say history is repeating per se?

 

[Alexko]

Nvidia has OpenGL extensions (such as bindless resources, multidraw and custom resource management) that provide similar performance boosts than Mantle. Sometimes Mantle is better, but for engines that are designed to abuse Nvidia bindless multidraw, it certainly beats Mantle in pure draw call count.

Is anyone actually using that?

 

[Blazkowicz]

Isn't that OpenGL 4.4?, rather than nvidia stuff?
All the new features, core and extensions in GL 4.4 are named GL_ARB_something and three of these new things are advertised as reducing the CPU overhead.
https://www.opengl.org/documentation/current_version/

For now AMD and Intel only support up to OpenGL 4.3. I tried to google things, and could find this

. According to Graham Sellers, OpenGL guy at AMD, the red team will be supporting this open API with some high performance extensions that will offer almost similar performance to AMD’s upcoming API, Mantle.

http://www.dsogaming.com/news/amd-aims-to-give-opengl-a-big-boost-api-wont-be-the-bottleneck/

It sort of implies AMD is working on OpenGL 4.4 support but no version is named explicitly. OpenGL extensions are evoked, but without explicitly saying whose extensions are they.

 

[Groovounet]

The bindless API is interesting because it means that when the GPU is executing something it can access any resources as long as the resource is in GPU accessible memory.

The bindless API is actually a less efficient API that the resource binding API but it provides that feature. Why having access to an "infinite" number of resources is interesting?

Because of MultiDrawIndirect (OpenGL 4.3, supported by AMD, Intel and NVIDIA) that allows the GPU command processor to submit itself the draws and for each draw we can index different resources in the GPU.

What's better than low overhead? No overhead. This is replacing CPU side resource switching by GPU based resource indexing.

From my experiments out of that stuff in a synthetic benchmark so that I could hit the GPU command processors bottleneck, I could launch 800000 draws per frame at 60Hz on Kepler and 300000 draws per frame at 60 Hz on Southern Islands.

This "CTM: closer to the metal" idea is BS, it doesn't mean anything. What that is mean in practice? What code it's going to allow you to write? That's the question we needs to ask ourselves when we think about graphics APIs.

 

[Groovounet]

If you are interested about what the current state of the OpenGL implementations, I am keeping track of that: http://www.g-truc.net/doc/OpenGL matrix 2014-02.pdf

Intel OpenGL drivers used to be absolute unusable crap back in 2007. These days Intel is 100% behind OpenGL and does an amazing job catching up. Reliability is pretty code and performance makes sense. So far the drivers supports OpenGL 4.2 + the most important OpenGL 4.4 and OpenGL 4.3 extensions. Back a year ago Intel was supporting only OpenGL 4.0 + some not so important OpenGL 4.1 and OpenGL 4.2 extensions. This is an astonishing work. http://www.g-truc.net/doc/OpenGL matrix 2013-02.pdf

I have good hope the drivers will support OpenGL 4.3 by Siggraph 2014.

 

[lanek]

I dont know why, but im not sure it is really part of a statment from him, but part of an article who have been made when Mantle have been released.

Is it really your work, or do you just cite some source ? on your second post, some here have ask about the methodology of the test and have put many question about this , but we have not see any response.. I can imagine, someone so much ported on developpement will be happy to respond to other developpers here.

This far, this give me strange feeling about your post. ( 4 post here and all about the same thing, if it was a developpers, i could imagine you will have take a bit of time allready respond about the question in your 2 december posts )..

 

[sebbbi]

Isn't that OpenGL 4.4?, rather than nvidia stuff?
All the new features, core and extensions in GL 4.4 are named GL_ARB_something and three of these new things are advertised as reducing the CPU overhead.

Yes, these extensions are now officially part of OpenGL. Nvidia used to have similar proprietary extensions before OpenGL 4.4.

Is anyone actually using that?

Yes

From my experiments out of that stuff in a synthetic benchmark so that I could hit the GPU command processors bottleneck, I could launch 800000 draws per frame at 60Hz on Kepler and 300000 draws per frame at 60 Hz on Southern Islands.

That's pretty much what you can achieve with multidraw (because of command processing bottleneck).

If you need to render more (say, up to 2 million objects per frame at 60 fps), you need to manually fetch (SoA layout) vertex data from raw buffers (do a manual indirection for vertex data -- it's similar to meshes that virtual texturing is to textures). This way you can render infinite amount of separate geometry with a simple standard draw call. When combined with virtual texturing (and some other ingredients) this pretty much allows rendering of the whole scene with a single draw call.