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/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?

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.

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