• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Interesting post on driver development Dx12/Vulkan/Mantle

Put it the opposite way then, if glide was hardcoded in to the hardware, then how comes you can run directx/OpenGL games on voodoo cards.

An Api is a software layer that allows a general software developer to interact with hardware via a recognised set of functions, by definition the api exists on the Pc, yes an api can be hardcoded to only work with one set of hardware via the interfaces that hardware exposes, but to say the api itself is hardcoded in to the hardware... It isnt the terminology I would use. It would mean that if glide was hardcodedin to the hardware, glide would be the only api that worked, the fact the hardware exposes an interface that can be used by more than one api means the hardware is just exposing an interface, not that glide is hardcoded in to the hardware.
 
andybird123 said:
Put it the opposite way then, if glide was hardcoded in to the hardware, then how comes you can run directx/OpenGL games on voodoo cards.

An Api is a software layer that allows a general software developer to interact with hardware via a recognised set of functions, by definition the api exists on the Pc, yes an api can be hardcoded to only work with one set of hardware via the interfaces that hardware exposes, but to say the api itself is hardcoded in to the hardware... It isnt the terminology I would use. It would mean that if glide was hardcodedin to the hardware, glide would be the only api that worked, the fact the hardware exposes an interface that can be used by more than one api means the hardware is just exposing an interface, not that glide is hardcoded in to the hardware.
Click to expand...

Its been a long time but if I recall correctly Glide was a mini cut down version of OpenGL focused on what games needed with all other stuff trimmed out.
 
Mauller said:
They used a "code wrapper" to emulate the glide calls into directx. Lookup nGlide. But the API itself was implemented directly into hardware for all of 3dFX's cards.
Click to expand...

Correct, hence all the Glide comparisons when Mantle was first announced.

IIRC also 3DFX actually sued the fans who made the original code wrappers lol.
 
The API could easily exist within Firmware on the card, the driver would then send Glide calls from the application to the relevant place, leaving no functional glide API code as software on the pc.

The hardware can still use other API's, the hardware function calls could still be accessed through the driver, using a software API on the computer, but to keep peoples hands off the Glide API code, it could have been stuck on a chip in hardware, which then performed the relevant API hardware translation etc.
 
Great write-up. I disagree with his closing point though, at the time I think DirectX and OpenGL did choose the correct path. When GPUs were still new and under rapid development a stable and somewhat black-box API was sorely needed to give some consistency, plus engine and tools development was very much still evolving. A low-level API in the early to mid 2000s would have been a nightmare.

Now that the architecture of GPUs has settled down and fundamental changes (like the change from fixed function to programmable) are unlikely and we have a selection of nice mature engines it makes sense.

I do worry about how hard it will be for a newcomer to learn graphics programming now though. I'll be interested to see what a rotating cube prpogram (the hello world of graphics) looks like in the new APIs.
 
Baboonanza said:
Great write-up. I disagree with his closing point though, at the time I think DirectX and OpenGL did choose the correct path. When GPUs were still new and under rapid development a stable and somewhat black-box API was sorely needed to give some consistency, plus engine and tools development was very much still evolving. A low-level API in the early to mid 2000s would have been a nightmare.

Now that the architecture of GPUs has settled down and fundamental changes (like the change from fixed function to programmable) are unlikely and we have a selection of nice mature engines it makes sense.

I do worry about how hard it will be for a newcomer to learn graphics programming now though. I'll be interested to see what a rotating cube prpogram (the hello world of graphics) looks like in the new APIs.
Click to expand...

Yeah, it'll be much more difficult with much more responsibility in the hands of the developer. That's why we'll probably only see the big engines and the big developers making full use of DX12 and Vulkan.
 
Baboonanza said:
Great write-up. I disagree with his closing point though, at the time I think DirectX and OpenGL did choose the correct path. When GPUs were still new and under rapid development a stable and somewhat black-box API was sorely needed to give some consistency, plus engine and tools development was very much still evolving. A low-level API in the early to mid 2000s would have been a nightmare.

Now that the architecture of GPUs has settled down and fundamental changes (like the change from fixed function to programmable) are unlikely and we have a selection of nice mature engines it makes sense.

I do worry about how hard it will be for a newcomer to learn graphics programming now though. I'll be interested to see what a rotating cube program (the hello world of graphics) looks like in the new APIs.
Click to expand...

The thing is, they could have abstracted the hardware, but still left the memory management and draw submissions up to the application, it is no different to just letting the driver do it all. the hardware to api calls is where all the changes occur as hardware changes.

For anyone writing console games or unmanaged applications using say, c++, you already have to do all your own memory management, so a lot of the knowledge is there, its just applying another memory manager to the graphics stack.
 
Yeah I think people wildly over-estimate the quality of code likely to be produced, lower level access is a road to much more broken software a lot of the time. There is a reason this stuff was all tucked away in the first place and I don't agree that it was a bad idea - nor even that we should now expose it all as the default. Does it allow good developers to write better games? Sure. Are there any developers who have only good staff? Not a chance.
 
A GPU from AMD or Nv comes packed with processing cores so any software needs to be threaded to get the most from a single GPU. So why is it then Crossfire/SLI is complicated for developers get right because essentially all your doing is getting another chip with the same processors to share the work load?
 
Freddie1980 said:
A GPU from AMD or Nv comes packed with processing cores so any software needs to be threaded to get the most from a single GPU. So why is it then Crossfire/SLI is complicated for developers get right because essentially all your doing is getting another chip with the same processors to share the work load?
Click to expand...

the load isnt the issue its latency and sync.
sli/crossfire is never going to be a good solution.
 
Bad coding has always been a problem, but it's been exacerbated by the developers not being able to see or work inside the DX black box. At least now developers can find and fix the issues in their own code, instead of letting the driver developers bodge in their own fixes after the release.
 
Mauller said:
The API could easily exist within Firmware on the card, the driver would then send Glide calls from the application to the relevant place, leaving no functional glide API code as software on the pc.

The hardware can still use other API's, the hardware function calls could still be accessed through the driver, using a software API on the computer, but to keep peoples hands off the Glide API code, it could have been stuck on a chip in hardware, which then performed the relevant API hardware translation etc.
Click to expand...

having downloaded the SDK's and source code... this is all bobbins

there is not a single reference to a "hardware" side to the glide API, all the documentation talks about the API simply being a cut down API that only exposes interfaces available on 3dfx hardware, nothing about the API being loaded on to the GPU itself

also, they frequently released updates and fixes for Glide, again looking through the release notes, there is mention of needing to update to the latest glide dll's, but nothing about needing to firmware update the cards... having owned several voodoo cards, I don't remember ever having to do a firmware update either... if the API was in the cards firmware, any new glide releases and fixes would need a firmware update

just comparing dll file sizes it doesn't make sense to say that glide primarily resided on the hardware
 
Last edited:
Just my interpretation on things i heard/read. Made it seem like it could have.

But in the end, at least we are getting Low abstraction API's again, which is the important thing. :)
 
David Bisset said:
Yeah I think people wildly over-estimate the quality of code likely to be produced, lower level access is a road to much more broken software a lot of the time. There is a reason this stuff was all tucked away in the first place and I don't agree that it was a bad idea - nor even that we should now expose it all as the default. Does it allow good developers to write better games? Sure. Are there any developers who have only good staff? Not a chance.
Click to expand...
The majority of AAA/AA games are produced on a small number of engines and those engines are already such impressive pieces of engineering and do so much that the extra work required to manage memory etc. for the GPU is hugely outwiehged by the benefits in flexibility, predictability and performance. Epic, Unity, iD, Crytek, Dice etc already have the engineering staff capable of making it work.

Can bad coders (or more likely bad management) produce bad games? Sure, but this change should generally make it easier for the good guys and the bad guys were going to make it bad anyway :)
 
You must log in or register to reply here.
Back
Top Bottom