5

I have the binary file, and it's over 200 MB in size, which makes me think that such a task by myself would be beyond incredibly difficult to get anything done. I am trying to see how the driver communicates with the GPU exactly (because I need to emulate a GPU for a science project), and I need at least SOME IDEA of how DX and OpenGL work on the GPU's end from inspection of the device driver. It's 32 and 64 bit, and it works on Windows, but that's hardly a concern since the main care is in figuring out how exactly it sends data/command packets, what addresses they are sent to, how it scans PCI/etc., and how this can somewhat help me draw a better picture on how the GPU's internal functions work without any documentation. I know this will be hard, and I will manage to simulate how I think it will work, and only emulate how I know it is accessed, and work from there. I ask here because I need some help from the pros here on these subjects:

1.How does one begin reverse engineering something of this tier?

2.How much of the GPU's architecture should I expect to learn from this process?

3.Will it be enough info overall to manage emulating/simulating the GPU somehow?

I am 100% serious, so I hope for some answers that can at least set me in motion.

Improve this question
4
  • 2
    If you want to do this from start, you'll probably need to dedicate the next few years to the project. However, people have been reverse engineering ATI and NVidia cards to produce free Linux drivers, you might want to look at what those projects have done. nouveau.freedesktop.org/wiki and xorg.freedesktop.org/wiki/RadeonFeature might get you started. The drivers are not complete yet, so they may or may not have implemented the features you're interested in. – Guntram Blohm Mar 25 '15 at 6:59
  • this is kinda redundant, but make sure you're good at windows drivers development. reversing will be much easier then compared to if you start knowing nothing – rev Mar 25 '15 at 14:00
  • @AcidShout It's not redundant if the end result is advanced GPU emulation that reverse engineering a device driver could help me accomplish. Most GPU emulation is very "high-level," and doesn't deal with the dark and complex operations of the chip on a lower-level. – Truffles In Ma Bred Mar 26 '15 at 19:49
  • Maybe this page can be of interest: "Free and open-source graphics device driver" (en.wikipedia.org/wiki/…) – wip Dec 28 '16 at 9:32
2

Hum ... Reverse engineering such a large piece of software will require a lot of will, time, and, of course, technical knowledge. Honestly, unless you're considering starting a company or providing an open source/free software version of the driver, you'll be practically wasting your time. Especially if it is for a science project.

You must keep in mind that reverse engineering is not an exact science, for that manufacturers always keep most of their technology under wraps. But if you're motivated enough, you must start by knowing how the target technology works. This can be "partially" accomplished by reading the available manuals and micro-benchmarking the platform (in this case the GPU). I can assure you though, most architectural details provided in the manuals won't be 100% accurate. You'll always end up having outliers in your micro-benchmark results.

Since you're more concerned by the GPU/Host communication protocol than the architectural aspect of the GPU, I would recommend you checking Ocelot. It's an open source emulator that targets GPUs and CPUs, and I'm sure will be a great source of information.

Know that if you're targeting nVidia's GPUs, the driver doesn't do much but load the PTX code in a specific memory area of the GPU where it'll be read from and executed. For more info about PTX go to this link.

Improve this answer
7
  • Yeah, I've tried Ocelot before and it's not quite what I'm looking for. While it helps a bit, it doesn't solve the tough problems at all, such as knowing the GPU pipeline and instruction set in finer details. And unfortunately, CUDA isn't close enough to the metal: I expected to emulate a GPU to a point where an actual GPU device driver can interact with the emulated GPU on a bare metal system level. A lot of what you say helps, but that is in assuming I'm interested more in a compatibility layer or execution layer but not actually emulating a GPU like a CPU, down to the stack/register level. – Truffles In Ma Bred Mar 26 '15 at 19:41
  • And yes, I wanted to make it open source and free if it proved worth it, based on how far I could get something going by myself. Basically, it will grow beyond me, but I want to get the wheels in motion first. Since a lot of GPU emulation is merely execution layer translations to host API functions, like OpenGL/DirectX, I wanted to tackle something I've never seen done before, which is system level GPU emulation from the ground up. – Truffles In Ma Bred Mar 26 '15 at 19:47
  • In that case, you're going to have to go through the architectural details of the targeted GPU, which are definitely not easy to find/figure out. Note that this will be specific to a certain hardware platform, and that it will be a huge mess to maintain and improve. I myself am responsible of hardware simulation for a well known microchip manufacturer, and I can assure you that even with access to confidential material it is hard to have great results. Bare metal is hell ! – yaspr Mar 27 '15 at 9:45
  • Simulation of microchips? At what level? You can simulate, say, a GPU at a super high-level (like with emulation) where a known function packet can be translated to a direct API call for a texel/bitmap (OpenGL, DirectX), or you can take it a step further and (with emulation) quantify each step the GPU would take, more or less, so as replication of it as accurate as CPU emulation in emulators can get, more or less; or, instead, one could just emulate the GPU at a level only necessary for most internal operations (opcodes, memory, etc.) and every tiny detail could be skipped/high level emulated. – Truffles In Ma Bred Apr 4 '15 at 2:25
  • To put it simply, we simulate the hardware to a nanoscopic precision. It's mainly CPUs coupled with integrated GPUs ... and we use a supercomputer for that. I believe it's a way more advanced level than an emulation of opcodes and instructions. We usually cover all the hardware (interconnection network, instruction pipeline, ...) along with the high level constructs (opcodes, registers, ... ). – yaspr Apr 4 '15 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.