Bye DirectX?

[frantaylor]

And more

If the entire stack is in hardware there is no more politics and no more whinging about which OS gets the better drivers, and when they get them.

[frantaylor]

more and more

If you want to do the virtualization thing right, then putting the entire stack in hardware is really the only way to go.

[DeepDayze]

GL-on-HW: they tried that with Glide. And that went well: cards that couldn't get any new functionality nor bugfixes.

Right now we have new GL extensions whenever the manufacturer feels like it, or GL 3 for GL 2 devices.

Think: Firmware updates! Such hardware with OGL onboard should only need a firmware update to add new functionality to the OGL code or to fix bugs. In the days of Glide, such cards did not have the OGL in firmware but hardcoded into the physical chips.

[curaga]

Think: Firmware updates! Such hardware with OGL onboard should only need a firmware update to add new functionality to the OGL code or to fix bugs. In the days of Glide, such cards did not have the OGL in firmware but hardcoded into the physical chips.

I am. The fact is the same from the 3dfx days, ASICs are 10x - 1000x faster than programmable chips.

[Khudsa]

I am. The fact is the same from the 3dfx days, ASICs are 10x - 1000x faster than programmable chips.

I think you are not talking about a FPGA, instead a memory in the graphic card with the programmable firmware with the OpenGL implementation. This is still faster than a software driver and make a more O.S. agnostic card.

[blacknova]

Think: Firmware updates! Such hardware with OGL onboard should only need a firmware update to add new functionality to the OGL code or to fix bugs. In the days of Glide, such cards did not have the OGL in firmware but hardcoded into the physical chips.

Well, given firmware updates are prone to errors and various issues, I'd opt against that. I think that developers need is much thinner API with ability to gain exclusive access to hardware. Strictly saying technicaly OpenGL is not better than DirectX since both of them reside roughly on the same abstraction level.

[squirrl]

So what am I suspose to use then?

The article goes to great lengths to discount using DirectX but doesn't suggest in my limited attention span of 3 pages what to use to program direct to the video card.


Is ATI going to release a guide? I give that article a 1 out 10 paws.

Back in the day bare-metal was:
push ax
mov ax, 13h
int 21
...

[blacknova]

The article goes to great lengths to discount using DirectX but doesn't suggest in my limited attention span of 3 pages what to use to program direct to the video card.


Is ATI going to release a guide? I give that article a 1 out 10 paws.

Back in the day bare-metal was:
push ax
mov ax, 13h
int 21
...

Hah?
That is just a bios programming this is not that much different from API calls. And besides DOS video interrupt is 10h
Close-To-Metal would be direct port programming.

[BlackStar]

Why not just have a standard hardware API. There is plenty of horsepower on both sides of the API, so you can just pick a convenient API. Why not just say "OpenGL IS the hardware API" Put all of OpenGL on the graphics card.

Impossible. You'd still need software drivers anyway, so you won't win anything, plus firmware design is an order of magnitude harder than software design (if OpenGL drivers suck so much, OpenGL firmware would suck *much* more; at least you can reset a faulty driver and continue - not so with a faulty firmware).

But this is impossible anyway.

Would the Gallium API be low-level enough for game developers? I can't say I'm really looking forward to having GPU-specific games.

Possibly. But (a) the API is still rather fluid and (b) it doesn't have - and won't achieve - the necessary market penetration.

[XorEaxEax]

The article goes to great lengths to discount using DirectX but doesn't suggest in my limited attention span of 3 pages what to use to program direct to the video card.
...

Guessing the obvious would be OpenCL, AMD is firmly behind it and I recently saw that they were hiring people to work on different areas of OpenCL, for example they were looking for programmers to work on optimally leveraging llvm for shaders.

The beauty of OpenCL would be that programs written in it runs on both CPU and GPU using the same code. And given that the future seems to be multicore CPU's with GPU's inside them (atleast that's how it seems to me with both Intel and AMD going for that solution) I think they are trying to position OpenCL as the best way to utilize that power. That said, this is just me speculating.