Originally posted by V-man:
From what evanGLizer said about beeing a third party in the game, the miniport driver, I gather that the IHV`s GL DLL calls functions inside the miniport driver, which finally takes care of the communication with the graphics card.
No, the miniport contains support routines for the display driver, not for the ICD. It also contains the hardware interrupt handling routines and I think that hardware initialisation routines as well, called by windows hardware config layer at OS startup.
The display driver normally accesses the miniport routines through IOCTLs (Input/Output Control calls).
Anyway, I just mentioned the miniport for completeness, almost all the opengl-related routines implemented in the display driver do not need calls into the miniport.
How does the switch between ring 0 and ring 3 occur exactly? The OS knows that you are trying to call a function inside a driver (SYS or VXD) and sets the CPU`s registers or …?
One of the ways of doing ring switching (besides causing a fault and thus tringgering the fault servicing routine) is by calling an interrupt (much in the way you called 10h interrupt in old DOS to access VGA BIOS routines, for example). This and other ways of ring switching are described in Intel’s x86 documentation.
Nevertheless, in Windows you never call the system interrupt directly, but you use Escape or ExtEscape win32 api function calls which allow you to issue escapes to the display driver.
Those driver escapes get serviced by the display driver in the escape servicing routine.
Why does the ICD ask for DMA buffers, hardware registers, graphics hw registers?
The way you can control a given hardware is either by:
- accessing its registers (via out/in instructions).
- accessing memory areas which are mapped to hardware registers.
- putting commands inside a buffer and telling the hardware somehow to consume them asynchronously from the CPU (DMA transfer mechanism).
So you need one (or more) of those three resources to be able to access any hardware. You need to map them, either to be accessible from the ICD, from the display driver or from both. In my previous post I explained why you need them to be accessible from the ICD (performance).
AGP memory is different since we know the famous NV function that gives us access to it.
Actually, I don`t know if I heard a explanation for that one. Howcome we can write and read from AGP memory.
Hmmm there’s a lot of confusion regarding AGP memory. AGP is just a piece of (normally uncached) system memory (RAM) that is mapped suitably through the GART (Graphics Address Remapping Table - see Intel’s link for more information).
Reading AGP memory doesn’t cause a fault, it’s just slow because it’s uncached.
The reason why it’s normally allocated as uncached is because the AGP protocol doesn’t snoop any of the CPU caches (this is different to how PCI protocol works), so either you flush your caches after filling the AGP memory or you just map that memory uncached and off you go.
Actually, it’s not totally true that the memory is mapped uncached, if available it’s normally mapped as “write-combined”, which means that the CPU will buffer writes to sequential addresses and send the data to memory in bursts (which acts as if you had a tiny cache). That’s why writing to sequential addresses of AGP memory is fast, but “reading” or “writing random addresses” is slow.
[On AGP accesses]
Shouldn`t it cause a fault?
I fail to see why it should cause a fault. If a piece of memory is mapped to be accessible from a user application, it won’t cause a fault.
Also, I beleive it should be possible to replace opengl32.dll
If all it does is load the IHV`s DLL and blindly route functions, anyone can write opengl32.dll
Brian Paul should have put some effort into this.
Sure, anyone can write opengl32.dll, and there are several “utilities” based on that fact (gltrace, wallhacks, etc).
I guess that the biggest problem here will be an IP one, AFAIK since the Farenheit fiasco, Microsoft is the only one with rights to implement OpenGL on windows.
One more thing:
When we install the video drivers, do the MS Direct3D DLL get overwitten?
The driver is independent from the directx dll.
[b]
So in essence , for D3D
myAPP –> ihv_D3D.dll –> port.SYS –> hardware
[/b]
Not exactly, it would be something like:
app -> MS directx layer -> IHV directx driver.
Assuming that the given function call the app used, forces a call to the directx driver (I think that MS’s directx dll normally batches calls and only calls the driver for drawprimitive routines and the like).
[b]
For GL,
myAPP –> opengl32.dll –> ihv_gl.dll --. port.SYS –> hardware
[/b]
Again, it would be something like
app -> opengl32.dll -> IHV ICD -> IHV display driver
And that’s assuming that the given OpenGL function requires a driver escape to be executed, otherwise (most of the time, even for rendering routines) the function call may just end at the IHV ICD.
[This message has been edited by evanGLizr (edited 08-18-2003).]