   Programming Directly to the GPU
  I''ve been thinking about programming a software 3D engine lately, because I need to know a little more about what goes on under the hood. But if you do they type of 3D programming where you get a pointer to the video buffer and go from there, you can''t get support from the 3D hardware. I''m thinking it''s probably because of drivers or something. From what I know, people like the ARB and Microsoft make a spec for their API, and chip makers like Nvidia and Ati make drivers for their chips that take a call (such as glVertex3f()) and do that processing in hardware. What I''m wondering is how do they do this? Is it possible to take advantage of a certain chip by programming routines especially for it? 
  No, you would need to write a driver yourself if you would want to use the hardware directly. And this is almost impossible without specs from the vendor. ;  I don''t see the problem with what he/she is saying...  Why couldn''t you just open up the openGL driver, which is a DLL, with a hex editor, this way you can see the hexadecimal equivalents of x86 instructions and how they send messages to the graphics pipeline on your card.  But it would be kind of hard trying to decode millions of lines of hexadecimal.  You better ask if there is a way to either disassemble a DLL.  I mean, why couldn''t you.  The Windows OS has a debug program that dissassembles exes and you can read them in plain mneumonic form.  I myself wouldn''t do this anytime soon, I don''t think it''s worth it.   ;  Of course you can disassemble the drivers. But even with the ASM source, I wish you good luck. Reverse engineering lowlevel register access to a complex hardware device without any specs, and only an optimized driver ASM disassembly, is much, much harder than you imagine. And that''s for a professional. It''s practically impossible for a beginner.If you really want lowlevel access, and you know what you''re doing, then you can check out the XFree drivers. Some manufacturers open sourced parts of the driver architecture.;  Here's a screenshot of a 7-day trial disassembler with a GUI:And here's a link to download it, and you can just open up opengl32.dll and look at all of the familiar symbols such as glVertex2f: MFVDasm.exe   [edited by - leinad on July 30, 2003 8:19:03 PM];  Microsoft has a Driver Development Kit (DDK) which hardware manufacturers use to build drivers for Windows.Just taking a driver (even if you had the card it dives) and disassembling it would offer very little information about the innards of the card.You''ll see port accesses and stuff which would be confusing, if not impossible to make sense of, out of context of an operation.Video card makers are quite jealous in protecting the methods they use to display stuff on the screen, so you''ll be very hard pressed to find out how something is done on the hardware.Bear in mind, too, that driving one card successfully with your engine does not mean you can drive them all.Best stay above the API for the moment and drive the hardware through Windows or some other API (DX or OpenGL). StevieDon''t follow me, I''m lost. ;  You could spend a lot of time figuring out how the drivers communicate with the hardware, but what would you gain from it? As a game developer you''d gain very little if anything at all. Your discoveries would have limited applicability (your code would only work with specific models of graphics hardware), all for very little to no benefit. Reverse-engineering hardware makes sense for driver developers who are denied access to the official specs, but rolling your own drivers is a waste of time for a game developer (except perhaps as a matter of curiosity).Graphics APIs already provide you with everything you need to develop games. Even professional computer programmers make use of APIs such as OpenGL and Direct3D, so why shouldn''t you do the same? ;  I understand where tuxx is coming from. Having such a simple thing as direct access to a screen buffer is just not technically available these days - Oh yes I hear all the DX and OGL ppl say; but its not really, its API based and there are a heap of things that DX and OGL just dont ''let'' you touch.This was one of the beauties of PS2 programming. The buffer was there, its a simple memory space, the back buffer and zbuffer again, simple memory spaces, you can and did want you wanted. I am a little worried personally the way PC hardware programming is going for graphics cards. Essentially pixel and vert or fragment shaders have introduced another layer of programming API into the fray - this is not what I would call a great idea. IMHO if there is to be programming on the GPU, open it up, make available the Vector unit programming, and such. Really in the long run shader programming will result in the programmer being able to write full sets of code on the GPU, so why not just make available the registers and GPU development software. This is how graphics advanced very quickly in the DOS days. If it werent for the ''tinkering'' of the Abrashes, and the Carmacks, we would hardly have ever heard of quake or wolfenstien.When you think about the complete depth of API abstraction that is going on to just write a pixel, I beleive like tuxx, that we may have lost the plot a bit, and need to get back to having more access less limitations. Sadly, I dont actually think any of this will ever happen on the PC. Mainly because noone wants to make a simple standard _hardware_ interface to graphical rendering. By doing this many, many problems are solved. The gfx companies can still write thier drivers, but the programmers could be happy in knowing that when address x is written the hardware does so...As for now tuxx, you can probably forget attempting it, mainly because of the problems involved with the hardware. Often drivers are used to mask hardware issues (ie used as a hardware patch) and so even across hardware revisions of the same card you will find that the code you write for one GPU may never work on the next.But honestly, if youd like some direct hardware access, and enjoy that kind of thing. Hit a console, its much more pleasing to know the registers and memory you write to are fixed across all versions, and you wont be forced to suffer the API blues again :-);  I personally find PS2 programming rather boring, + giving direct hardware access would be completely pointless on PC since the whole point about OpenGL and Direct3D is to provide a common API for all the cards.;  Don''t expect to be able to program hardware if you can''t program software...I wrote a software renderer with ps 2.0 emulation (swShader), and a month later Nvidia contacted me for an offer. It took me three years to gain the knowledge to write this program and I still know only a fraction of 3D graphics complexity. 