Funding Radeon driver development

[Alex Deucher]

On 4/16/07, Russell Shaw <rjshaw at netspace.net.au> wrote:
> Alex Deucher wrote:
> > On 4/16/07, Russell Shaw <rjshaw at netspace.net.au> wrote:
> >> Alex Deucher wrote:
> >> > On 4/16/07, Russell Shaw <rjshaw at netspace.net.au> wrote:
> >> >> Alex Deucher wrote:
>
> ...
>
> >> > All that aside, what sort of documentation do you feel would help you
> >> > understand this better?  A conceptual overview of how modern cards
> >> > work?   A basic tutorial on setting a mode?
> >>
> >> An api that encapsulates everything to do with setting up, changing
> >> modes,
> >> and running the card. That way, any extra detail i need inside the card
> >> driver can be put into context by what is calling it. All the cards
> >> should
> >> have the same api, making the learning and debugging procedure
> >> consistant.
> >>
> >> Such an api may already exist in X or DRI, but there's that many entry
> >> api points scattered around X and card drivers that i haven't figured
> >> out what the one-and-only current api is, and what others are deprecated
> >> things.
> >>
> >
> > http://ftp.x.org/pub/X11R6.9.0/doc/html/DESIGN.html
> >
> > The link above lays out the basics of what is required by the DDX and
> > how control flows.  The rest is generally handled however a driver
> > sees fit.  Generally functions with 'init' in the same set up register
> > state, functions with 'write' or 'restore' in their names write that
> > state back to the hardware, and functions with 'save' in their names
> > save the previous register state for things like VT switch.  most
> > drivers follow very similar patterns (or in many cases are copied and
> > pasted from another driver).
> >
> >
> >> >> What i really wanted is an openGL graphics driver infrastructure for all
> >> >> cards that is external to X. I haven't figured out how to separate DRI
> >> >> from X yet.
> >> >
> >> > The DRI is separate from X for the  most part.  The kernel radeonfb or
> >> > vesafb driver and miniglx may what you are looking for.  Miniglx uses
> >> > the kernel FB drivers for modesetting and hardware setup and the DRI
> >> > for 3D.  No X involved.
> >>
> >> I've looked at the kernel console and DRM stuff, but i still haven't
> >> figured out how the basic console stuff works in the overall context
> >> of the normal kernel operation (i need to understand more kernel basics).
> >>
> >
> > Well, at the moment, the drm doesn't really do much other than feed
> > drawing commands to the hardware and handle DMA.  All of the mode
> > setting and much of the general set up still happens in the DDX (which
> > bangs the hardware directly).
> >
> > DDX - userspace; sets up the card and modes/outputs, handles 2D accel
> > (with or without drm assistance) and video overlays
> >
> > DRM - kernel; verifies and submits drawing commands and DMA
> >
> > DRI - userspace; 3D driver.  sets up the hardware state and submits
> > the resulting commands to the drm.
>
> Hi,
> None of that defines the openGL drawing commands i can send to the graphics
> card. I guess the answer is to look in the mesa source which i haven't done
> yet. Is mesa a neccessity for driving a graphics card or is it just a software
> fallback for operations unimplemented in hardware?

I should have said mesa rather than DRI above.  mesa contains both the
3D HW drivers and the software implementations.  for the HW 3D drivers
you'll want to look in src/mesa/drivers/dri:
http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=tree;h=30a39d8225e0e455b59ed8ac1967f9e7bbfbee34;hb=badc346206453714e95e19d381e1a0495b63ceab;f=src/mesa/drivers/dri

Alex