Interaction with graphics Hardware

[RedXVII]

I am curious, i have quite a few questions.

I get the processor and the memory easily enough, but i was wondering what really happens when you lets say; call a directx function and how it "uses" the graphics card. How does the directx library give stuff to the graphics card to process? or does it go, directx -> windows -> graphics card?  :eek Im also mainly taliking here in terms of assembly language. Anyone got any direct information i could read while im at it?

A better explination would be, lets say i wanted to emulate the opengl or directx libraries in some way, or even create my own graphics library. How would one do this?

Thanks for any knowledge you share
RedXVII  :U

[Tedd]

I presume it goes: directx -> graphics-card-device-driver -> graphics card

Since each card is different, the manufacturer will provide the device driver and make it compatible with directx/opengl -- those libraries then use the support provided, rather than needing to support every known (and unknown) card.

I suppose the best place to look for such info will be from the linux side, where most drivers aren't directly available (they only target windows) so users are left to attempt to write their own.

http://dri.freedesktop.org/wiki/
http://www.xfree86.org/

[drhowarddrfine]

The problem is the manufacturers won't let you know how to talk to their hardware.  So you need to go through the drivers which is what DirectX and OpenGL does.

[RedXVII]

Ted, you gave me an idea to look up some official documentation for the drivers, with the hope of finding something useful. Alas, i dont know much about drivers and (like drhowarddrfine said) couldnt find a thing. It would certainly be nice to be able to use the drivers to render something, completely "bypassing" (more like emulating) opengl and directx libraries. But I thaught such a topic of inputs/outputs and accessing drivers was handled by the OS only. Cant find a thing.  :'(

Im just curious as to how exactly directx/opengl access the grapics card. If no one knows, i suppose i could spend a few days debugging  :bg

Update before i post: I just came accross an ati radeon SDK. i wonder what this is... downloading now...   

If anyone knows anything about this topic, please please point me in the right direction  :U

[RedXVII]

Crap, that was just some directx/opengl development pack. Coundlt find anything related to what i am looking for. Im going to dig up some books on how windows works and hope the answear may lie there.

Thanks anyway

[RedXVII]

Is there anyway of directly accessing the graphics buffer(s) and do stuff with it?

[BogdanOntanu]

AFAIK there is no way to do this in Windows.
You wil have to use the interfaces provided by either DirectX or OpenGL.

The most you can do is to use old DirectX 7 or lower interfaces and to get a pointer to the primary buffer, that "primary buffer" represents the visible video memory of the board. You can access that directly and "do stuff with it"...  (do not read because it is slow, just write)

But by doing this you will NOT benefit from the 2D or 3D acceleration of the board... so you will have to be quick and simple

On your own OS or Solar_OS (www.oby.ro) or other OSes that will allow you to interact directly with the hardware... this CAN be done.
However you need advanced hardware information and huge experiennce with drivers and hardware.
It is very unlikely to have or to obtain this level of expertise very fast.

Besides there is NO information available (it is a secret) about the latest video boards from NVidia or ATI ...
Again unless you have great experience and knowledge this is a road to frustration

It will require a lot of work, and the results are uncertain because you do not have the original documentation to clarify.
And you will have to do it again and again for every new board or version that appears on the market!

IF this is the road you would like or want to take then I do suggest readin this:
-Intel documentation about I810 and I815 shared memory video boards
-ATI and Nvidia opene sorce drivers in Linux
-Voodo3 2d/3D accelerator old documetation that is available because Voodo was aquired and went out of bussiness

This will get you started... but by very little ... and it is a very long and hard road ahead of you...

For example I wonder IF you can understand anything from the documentation that Intel is so kindly offering about their video boards?
Do you even imagine how it will be like to have to understand all this without the documentation?

Or you could wait until we release SolarOS'e first accelerated video drivers :D

Now let me ask you frankly... WHY do you want to do this?
Maybe there is a better solution to your problem / requirements... but it depends on your real target...

[Mirno]

Take a look at matrox's graphics drivers, they've released an open source version of their linux driver (well most of it is open source, there's also a closed source lib with it too for the private stuff).

Basically how the graphics card works is this:
#1 Basic functionality is provided via the BIOS on the graphics card, this gives the card enough setup to run in a nice and safe way, to drive the monitor at 60Hz, and at the resolution to display text (the BIOS boot screen, etc.).

#2 Windows will load the driver provided by the hardware vendor, and the driver will query any PCI busses on the motherboard searching for the vendor ID and device ID codes it knows about. On finding one it knows about, a part of the generic PCI information pertains to the memory mapable areas of the chip. On a graphics card these will be register space and the memory on the card (although there are usually two copies of the register map and one will be byteswapped so they can sell the card to macs too). The driver will then get these mapped in to the physical address space on the PC. Take a look on the device manager, at the "resouces" section for the card the "memory range" details the physical address the card is mapped in to (note that this is physical address, so you can't touch it as your apps run in logical address space).

As the card now is now in an address space the CPU can see, it can perform DMAs etc.

#3 The driver will now convert DirectX function calls into the appropriate accesses to the physically mapped card. Some will only require register accesses (these tend to be very simple atomic operations), but most will be done by composing a list of jobs and DMAing the list over to the cards memory in one lump. When the DMA is complete it will then write to the appropriate registers to tell the card the data is ready and at what location on the card to look for it.


The registers will do things like turn parts of the chip's functionality on or off, set thresholds and priorities for things like the memory controller, set video timings, memory timings (and types of memory), clock frequencies, give access to the cards BIOS (for flashing). Also as the card will be in use you cannot safely access it as you'll be fighting with the driver.

If you are serious about really looking at the hardware, and trying to figure out what it does, then you'll need to get a second graphics card (not an SLi type thing, but a PCI card (make sure it's not the same manufacturer it's easier that way)). Set the PC to boot with the PCI card as the display, set windows to disable the card you're actually going to probe and reboot.
At this point you're ready to write a simple driver that can scan the PCI space looking for the vendor ID of your card.

http://www.pcidatabase.com/ is a good source!
0x10DE for nVidia
0x1002 for ATi
0x5333 for S3

Once you've found your card, you can map it in and mess around!
Be warned, this is VERY dangerous, you're likely to permanantly damage your card if you do this and don't know what you're doing.

I've done this with hardware I knew about, and even then programming errors cause blue screens!

Mirno