Funding Radeon driver development

[Alex Deucher]

On 4/16/07, Russell Shaw <rjshaw at netspace.net.au> wrote:
> Alex Deucher wrote:
> > On 4/15/07, Russell Shaw <rjshaw at netspace.net.au> wrote:
> >> Daniel Kasak wrote:
> >> > Firstly, I thought I'd start a new thread instead of replying the the
> >> > original one, as I'd like to get maximum exposure and not just people
> >> > interested in tv-out ...
> >> >
> >> > Hanno Böck wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> One of the most missing features for me in linux is my non-working
> >> >> tv-out. (well, it can work with the proprietary ati-driver, but that's
> >> >> not really what I want)
> >> >>
> >> >> Now, I heared that some people were working on that, but never saw a
> >> >> patch that made it work for me. As this would make things much easier
> >> >> for me, I thought that I might donate a small amount of money if
> >> >> someone is willing to pick that issue up. I also think that I could
> >> >> gain some more donaters via a public announcement in my blog.
> >> >>
> >> >> My question: Would such an initiative be welcome by the xorg-devs?
> >> >> Anyone probably already interested in getting such a bounty?
> >> >
> >> >
> >> > I've been meaning to suggest something similar, but I've been snowed
> >> > under in work and stuff. I think the bounty idea is a great way of
> >> > motivating both users and developers...
> >>
> >> Geez, i've had *months* of free time to write drivers for *free* and have
> >> tried just that for the ATI 9200 card i have.
> >>
> >> The failure of xorg is to document anything about writing a card driver,
> >> how existing ones work, and how DRI works.
> >>
> >
> > There is a fair amount of documentation, what aspect were you having
> > trouble with?  Also, I've said this before, and I'll say it again, if
> > you need help understanding something, please ask!  Email the list or
> > me directly if you want.  I'm happy to explain anything I have
> > knowledge of:  crtcs, outputs, drawing engines, how a mode gets
> > programmed on a radeon, etc.
> >
> >> Even though i've worked out a lot of it by looking at source code over
> >> years, there's too much undocumented stuff such as the dozens of card-
> >> specific non-vga registers and configuration code that makes it
> >> impossible to understand the hardware well enough to write and debug
> >> X driver code.
> >>
> >> The first thing that could be done is to document what driver code
> >> is based on proprietory NDA data, and what was reverse engineered.
> >>
> >> Money spent on X driver documentation or howtos is far less wasteful
> >> than X conferences (of which i'll never go to anyway).
> >
> > Well, what sort of documentation do you want or think you need.
> > Seriously.  Perhaps we can start putting something together.  I feel a
> > lot of people say we need documentation, but no one can clarify beyond
> > it's too hard for me to understand and then a bunch of hand waving.
> > What aspect of the driver did you want to work on?
>
> I wanted to know enough so that i could use the drivers stand-alone in my
> own windowing system. For compatability, X apps would run in their own X
> environment in their own top-level window of my windowing system. The goal
> is to make a better (in many ways) windowing infrastructure than X. I can
> do it on my own embedded system with my own video hardware, but not on a
> normal pc.
>
> >> If i had've had enough information to hack my radeon card, the ati driver
> >> could've been by now *bug free*.
> >>
> >
> > Unfortunately pretty much everyone is in the same boat here.
> > Databooks are not some magical panacea of knowledge.  They are pretty
> > much what you see in the driver reg.h files: register offsets and bit
> > fields, often without descriptions.  You really just have to dive in
> > and start playing with the driver and asking questions.  Working
> > source code is *invaluable*.
>
> There's such a large number of register bits in radeon_reg.h that just
> playing with crash-and-burn methods will take forever to conceptualize
> everything. Then the same understanding would be needed if other chips
> were to be used.
>

Not really.  Most hardware operates very similarly.  If you learn one,
others make sense easily.  Most modern display hardware has one or
more crtcs, several outputs (DACs, TMDS, LVDS, etc.) and some routing
regs.  Almost all 2D engines operate in the same surface based manner:
src and dst surfaces with x/y and w/h rectangles.  And finally fixed
function 3D engines generally follow the same pattern too:  a small
number of state and offset regs and a bunch of vertex and texture regs
that more often than not, follow D3D or OpenGL formats.

And it's not just crash and burn, you can look at the driver functions
to see which regs do what.  For example in the radeon driver:

RADEON*CRTC() - crtc1 regs (primary display controller; the primary "head")
RADEON*CRTC2() - crtc2 regs
RADEON*PLL() - primary video clock
RADEON*PLL2() - secondary video clock
RADEON*DAC() - primary DAC
RADEON*FP() - internal TMDS
etc.

* = Init or Restore or Save
Init - set up the register state
Restore - write the state back to the hardware
Save - save state

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?

> 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.

Alex