driver implementation and design

Are there any books out there which seriously explain how an OGL driver works? (Even DX is ok)
This is a firstly a WHY(design) and secondly a HOW question.

I mean a read that explains in depth stuff like:

  • interpipeline stage caches and how are they designed (ex: geometry shader cache vs tess cache… first thing to cross my mind really)
  • rasterizer patterns and their motivation (i know how i can observe them with atomics, interested in design)
  • flushing buffers
  • object lists
  • memory layouts (“texturing” caches for example)
  • opengl cpu side - gpu side… syncrhonization, multithreading(dx only for now), priorities.
  • specialized hardware (rasterizer unit(s), tess units, etc)
  • hardware architecture and the differences ( for example why does only nvidia have extensions that enable the paging system in this: http://blog.icare3d.org/2010/07/opengl-40-abuffer-v20-linked-lists-of.html )
  • how to such topics interact with each other
  • many other

I have read stuff like this(and other): https://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/ and even if it is an awesome read and even if I have a very decent ideea of how all the things mentioned in this post work I want much more detail like a good book to put it all into context not just bits of information.

Much of what you’re talking about is hardware design, not driver design (or the two working in concert). Caches, etc are all hardware functionality.

hardware architecture and the differences ( for example why does only nvidia have extensions that enable the paging system in this: http://blog.icare3d.org/2010/07/open…-lists-of.html )

I don’t see anything there that’s NVIDIA-specific. Indeed, the only thing I see that seems to deal with NVIDIA/AMD is the bit at the end, where an early EXT_shader_image_load_store implementation seemed to have bugs in AMD’s drivers.

[QUOTE=Alfonse Reinheart;1244625]Much of what you’re talking about is hardware design, not driver design (or the two working in concert). Caches, etc are all hardware functionality.

I don’t see anything there that’s NVIDIA-specific. Indeed, the only thing I see that seems to deal with NVIDIA/AMD is the bit at the end, where an early EXT_shader_image_load_store implementation seemed to have bugs in AMD’s drivers.[/QUOTE]

I’m sorry, I can’t agree with your response, maybe my question was too poorly specified, so here’s another go at it:

Per shader model (say we take sm5) design of driver must have a ton in common (and of course differences). Pipeline is too big with too much specific functionality not to have alot of similiar design decisions. Sure, some things can vary but it’s impossible to think that there is no common denominator.
For the gain/transistors i find it hard to imagine that any video card does not have specialized rasterizer units. The same with the implementation of tessellation unit(s). The latest series of amd and nvidia have similiar rasterizer patterns. Or that a post transform cache size is sufficient from some value N…this should lead to some pretty convergent design. We can come up with quite alot of examples in SM5.
I’m not talking about driver interrupt handling, i’m talking about a more indepth but still somewhat general presentation.

if you look closely besides the imageloadstore(that the amd guy ported), in a different shader path he also does use http://www.opengl.org/registry/specs/NV/shader_buffer_store.txt which, as far as i know, is not quite the same thing as http://www.opengl.org/registry/specs/ARB/shader_storage_buffer_object.txt … global gpu adress and all.
How come arb does not offer this with ssbo?(of course we can emulate with a big buffer but do we get comparable performance?)

Not only these but for example a context talk about … say … fence objects and how are they scheduled or alot of other things. I find there is alot of stuff which exists in both DX and OGL specification about which there is few information available

So, to restate the purpose of this thread:
a) ANY information about driver implementation and/or policy that goes a bit more indepth.
b) Flavor stuff is a bonus: “on gtx470 nvidia the rasterizer uses 8x2 tiles because they perfectly…etc”. Historical evolution if a bonus too. But my main interest is a). (i know this subpoint is kind of pushing it for an opengl forum but it’s really related to the overall post)

Why don’t you go look at the Linux open source OpenGL driver stuff, and ask that community? You aren’t going to get open development information about proprietary ATI and NVIDIA drivers. Private industry writes whatever they write. They aren’t going to to write books on it clarifying things for you. I’ve done the OpenGL driver writing thing for money before, a long time ago. Their philosophy is that because they’re head of the pack, they want to keep their designs and techniques secret to the extent they can. Intel is doing a lot of Linux open source driver stuff now, because they’re not head of the pack. So they hope to compete by being more open, and it’s a good strategy that’s winning a lot of positive feeling in the Linux world. No less than Linus Torvaldis gave NVIDIA the middle finger this year, so that ought to tell you something about how much good quality information you’re going to get.

If your purpose is to go get a job, don’t overthink it. Just go get a job and get paid to grunge with all these little details. The details are going to be different for every vendor. If your purpose is something else… well, academic fascination is all very fine and well, but you can get paid big money to grunge with this stuff! If you’re trying to implement open source drivers, talk to the open source crowd.