On 2002.05.15 23:17 Ian Molton wrote:
> On Wed, 15 May 2002 22:42:25 +0100
> José Fonseca <[EMAIL PROTECTED]> wrote:
>
> > Ian,
> >
> > On 2002.05.15 21:39 Ian Molton wrote:
> > > ...
> > >
> > > Here are some things I think should be worked on:
> > >
> > > 1) I *NEED* info about what cards have what features supported by
> > > DRI, like the radeon driver does already.
> >
> > I think that more important than raw data is to establish a easily
> > parsable format for that (either XML, or plain comma-seperated-values)
> > and a template for the property sheet so that it can be easily
> > maintained.
>
> I agree. I just want the values for the 'first pass'. Do you know if the
> server is running any database or such?
>
> What facilities do I have with which to play?
Take a look to SF documents (http://sourceforge.net/docman/?group_id=1),
section 7, especially the
http://sourceforge.net/docman/display_doc.php?docid=4297&group_id=1 .
You'll probably want to reuse much of the stuff thats is in the site. I
don't know in what scripting language that is.
> > > 3) Can people help me compile a list of janitorial tasks that could
> > > be undertaken by new developers? perhaps installation cleanups, or
> > > trivial driver tidyups ?
> >
> > I don't think that we should frustrate the potential new developers
> > expecations with janitorial tasks.
>
> I wasnt suggesting that we foist jan. tasks on them specifically, but I
> do know that having a big selection of tasks will encourage a broader
> range of newbies. Plus it gives a stepping up point for the lesser
> skilled programmers oiut there.
>
> > I'm of the opinion that if one can code then one should do it. The
> > janitorial tasks should be taken by users that want to aliviate the
> > developers load so that they code more.
>
> Well, lets present all our little tasks, so people can pick and choose.
>
> > I think that the two most rewarding things that a potential developer
> > can do is enhance the documentation and/or bugfixing. Both these tasks
> > contribute to quickly generate the required know-how to start working
> > on missing features. They give you better understanding of the
> > architecture and the code.
>
> Definately.
>
> > I can be more specific:
> > * Documentation:
> > - update the existing documents
> > - change the code comments to Doxygen so that we can automatically
> > - generate reference manuals of the subsystems and the drivers.
> > - add more items to the Developers' FAQ
> > * Bugfixing:
> > - Basically pick a bug on the card of one's choice and hunt it
> > down!
>
> Or, pick an unimplemented feature and let rip :) All the more reason to
> need feature lists.
>
> > > 4) Can people who have information about the intimate details of
> > > card HARDWARE (eg. register locations, DMA engines, etc.) please
> > > send me them, so that I can add them to the developer documents?
> >
> > Mike Harris posted recentely a link with this information for 3DFX,
> > but this a rare exception. Most of the documents that the current
> > developers have are under NDA (see
> > http://dri.sourceforge.net/doc/faq/getting-started.html#NDA).
>
> Indeed I shall.
>
> > > 5) Can someone with a nice package re-draw the DRI flowcharts? the
> > > Precision Insight ones look like Fischer Price 'my first
> > > flowchart'...
> >
> > I kinda link their style... ;p
>
> perhaps they are OK for a conference, but I think they need prettying
> for normal developers. They /dont/ show layering clearly.
>
Well, even more important, there are slightly outdated too. Jens posted an
avaliation of the documentation state some months ago. I attached my local
copy (which is meant to include it the FAQ references eventually).
"dia" and/or "sodipodi" are two nice applications for this. (I'm a gnome
desktop user).
> > > So, lets get to it :)
>
> > Good luck,
>
> Yep.
>
José Fonseca
David Johnson wrote:
> Could the DRI experts offer some feedback on the relevence and usefullness
> of the following documents. Are the reasonably up to date? Are they
> moderately up to date? Are they out of date and not extremely useful with
> respect to the current DRI artitecture?
I'll throw in my two cents...
> 1. Introduction to the Direct Rendering Infrastructure - Brian Paul, August
> 2000
> http://dri.sourceforge.net/doc/DRIintro.html
Reasonably up to date. Decent Intro.
> 2. Dri term glossary. http://dri.sourceforge.net/doc/glossary.html
> I suspect this doesn't need to be changed but is there anything that should
> be added?
Reasonably up to date--except the author, Nathan, no longer works for
VALinux->so his e-mail address is invalid. Useful.
> 3. Data flow diagram
> http://dri.sourceforge.net/doc/data_flow.jpg
Very high level. Good for someone brand new to the concept of direct
rendering--we'd use this at trade shows to explain what we are doing at
a very high level.
> 4. Control flow diagram
> http://dri.sourceforge.net/doc/control_flow.jpg
This is moderately up to date (and moderately out of date). I find this
very useful as a module map of where all the pieces go and how they fit
into the big picture. So, I guess this is the "big picture" :-)
That's why there is a big version at
http://dri.sourceforge.net/doc/control_flow_poster.jpg. A developer
interested in writing a new driver should focus on the Red Boxes. Those
are the pieces that need to be recreated for each new device.
Items that are out of date include:
- The modules in the kernel for the DRM. There is no layering and there
is not generic driver. There should be a red box labeled "DRM Driver".
- The layers at the top of the "OpenGL Compatabile Core Rendering
Library" between a 3D client side driver and the application.
- Need to deemphasize the MMIO path and make the DMA path easier to
follow because all drivers since 3Dfx have used that path.
- Consider adding the agp modules to this diagram.
> 5. A Multipipe Direct Rendering Artitecture for 3D. Jens Owen, Kevin E.
> Martin. September 1998
> http://dri.sourceforge.net/doc/design_high_level.html
Surprisingly, these is moderately up to date. I don't recommend this
for somebody wanting to write their first driver--rather, it's a high
level design document written before we implemented any of the DRI. It
helped us focus on the design tradeoffs we wanted to make. This is
somewhat useful to anyone wanting to change the DRI framework. It gives
a good idea of our original design goals.
> 6. Direct Rendering Infrastructure, Low-Level Design Document.
> Kevin E. Martin, Rickard E. Faith, Jens Owen, Allen Akin
> http://dri.sourceforge.net/doc/design_low_level.html
This is woefully out of date, and not needed by developers tackling
their first driver. This *might* have some value for developers looking
to push the infrastructure envelope; however, I think the following docs
are more useful...
> 7. The Direct Rendering Manager: Kernel Suport for the Direct Rendering
> Infrastrucure. Rickard E. Faith
> http://dri.sourceforge.net/doc/design_high_level.html
You've got the wrong link here. It should be
http://dri.sourceforge.net/doc/drm_low_level.html
Although this hasn't been touched since the DRM library was first
implemented, this is still a moderately up to date document. It does a
decent job of documenting the DRMLib interface (The yellow box labeled
"DRMLib" in the control flow diagram). Since the DRMLib interface is
used by and supported by a device specific driver suite--it is good
reading for first time driver developers.
Items that are out of date:
- Layering of DRM support, no more layers or generic driver; we now have
DRM templates developed by Gareth.
- Security Mechanism is slightly different. The flow of approval was
reversed--but I don't remember the exact details.
- This interface has been extended for some drivers...driver specific
IOCTL's added.
> 8. Hardware Locking for the Direct Rendering Infrastructure. Rickard E.
> Faith, Jens Owen, Kevin E. Martin
> http://dri.sourceforge.net/doc/hardware_locking_low_level.html
This document is in decent shape. However, we don't use hardware
locking very much for DMA based drivers; and it's really a
infrastructure design justification. Not recommended for 1st time
driver writers; better for developer wanting to extend the
infrastructure and needing a low overhead lock.
> 9. A Security Analysis of the Direct Rendering Infrastructure. Rickard E.
> Faith, Kevin E. Martin
> http://dri.sourceforge.net/doc/security_low_level.html
Out of date in that the mechanisms have changed. Also, not very
relavant to 1st time driver writer.
> 10. DRI Extension for supporting Direct Rendering Protocol Specification.
> Jens Owen, Kevin Martin
> http://dri.sourceforge.net/doc/dri_extensions_low_level.txt
Reasonably up to date--but only useful to somebody wanting to change the
infrastructure. A document describing the API in the DDX drivers that
support this extension would be much more useful to the driver
developer. Specifically the API defined by the header
xc/programs/Xserver/GL/dri/dri.h. This interface is supported by a DDX
driver in the X Server and is what makes a DDX driver into a "DRI aware
DDX Driver"; the red box in the middle of the control flow diagram.
I hope my two cents will help.
Regards,
Jens
