Funding Radeon driver development
rjshaw at netspace.net.au
Mon Apr 16 19:55:37 PDT 2007
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
>> 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
>> have the same api, making the learning and debugging procedure
>> 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
> 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.
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?
More information about the xorg