I would like to know how we turn these register documents into nice linux drivers? When I look at the evergreen referece, I see what looks like the assembly code of my Patterson architecture book. Now that I think of it, How do we wrangle our datatypes into the SIMD extended instruction (or other multimedia instructions) set for processors without help from the compiler?
Announcement
Collapse
No announcement yet.
what does open source driver programming look like?
Collapse
X
-
-
Originally posted by dacresbu View PostI would like to know how we turn these register documents into nice linux drivers? When I look at the evergreen referece, I see what looks like the assembly code of my Patterson architecture book. Now that I think of it, How do we wrangle our datatypes into the SIMD extended instruction (or other multimedia instructions) set for processors without help from the compiler?
That gives you more of a top-to-bottom view of what is required, at least from a drawing / acceleration point of view. Look at the diagram on page 8, then read through the steps starting on page 12. That part of the doc walks you through the main steps a driver must perform when drawing.
For simpler functions, such as those used in 2D acceleration (EXA and Xv APIs) Alex hand-coded the shader instructions with a bit of help from the shader compiler that Richard was working on at the same time. Remember that vertex and pixel (aka fragment) shader programs are what run on each individual vertex and pixel, so in some cases they can be as simple as passing the vertex information from input to output, or reading one pixel from a texture and outputting it to the next hardware block (DB/CB, or Depth Buffer / Color Buffer).
You'll see a couple of places in the doc where "loading the shader program and telling the GPU where to find it" are mentioned -- the ISA doc (like the one we just released for Evergreen) tells you exactly what those shader programs should look like.Last edited by bridgman; 23 December 2009, 01:11 PM.Test signature
Comment