Funding Radeon driver development

[Russell Shaw]

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?