i wont mess with trying to respond in line. but i have been lurking on this list for the last year ( which is more of an investment than you might think! ) and it appears that adoniz makes some valid points, tho perhaps in an overly vigourous fashion. :-)
well, every OS project is different ( recall the line about families in anna karenyena :-) ). This is probably the most technically complex one in existence - a good graphics card is effectively another computer. there is further irony in that this project provides the functionality that supports the one thing that the most technically illiterate user cares about...GAMES! ( ok, well people want a word processor too, but that's another project ). things have grown even more fascinating with the IP transfer from SGI to M$FT. it occurs to me that we can soon expect M$FT to start waving lawyers at all things OpenGL. They may not have a case, but they have lawyers, and that actually amounts to the same thing for 90% of the world. so, where does that leave me and my SiS/FreeBSD combo? same place i was last week :-). no matter, i'll go src spelunking and take a few notes, and maybe bake up a few perl scripts to generate some annotation. that way i can track what changes and add it to the notes. if i want to make dri documentation, no one can stop me BWAH-HA-HA-HA! and i shall rule the world! and townsville! and defeat, once and for all, those meddlesome power puff gi.... oops! wrong thread. so, adoniz, you alluded to have written a stub. care to share? hava a pleasant day one and all... johnu On Thu, 17 Jan 2002 [EMAIL PROTECTED] wrote: > > Okay, sorry, I just had to laugh. Not your fault, I admit that. You are as innocent >as I used to be. > > Here's the deal bro: > > [RANT MODE ON] > > Sometimes it seems that the DRI project is for a "special" group of people who are >(either,or,and,not,etc,etc): > > 1) special, either because they designed it, or because they already had 18+ years >of X11 + graphics industry experience > > 2) they came from 3DFX, SGI, HP and other big names who had lots of personel working >on grafix > > 3) they design it themselves and don't need to make docs for others > > 4) or if they do make docs, they do it because else it won't be regarded as official >or it won't "sell" (contracts for making drivers) to big names like ATI or Matrox who >will hire these people to make DRI drivers for them > > 5) and after the first bunch of docs which are more like pre-design docs, the design >changes radically leaving these docs in the dust and making a new comer even more >confused, because some people still claim their are uptodate: what a bunch of >horseshit. > > 6) (these people) don't think back to the times when they needed a helpful start, >and think that everyone is just gonna jump on the X11+DRI+Kernel gorilla and start >hacking. Yeah, right! I was speaking assembly at age 2 and X11 calls at age 4. NOT >!!!!! I _read a lot_ (like most of us? i hear agreement) before I learned the things >I know. > > Anyways, the above things are sometimes true, othertimes not, for others partial, >for others full. Take it as you will. With a grain of salt or none at all. That has >been my experience at times. > > I have tried time after time to elicit from the DRI project any kind of useful info >so that I could actually help the busy DRI developers (they are only a handful), by >creating some devel. docs myself and of course working on 3D drivers. All I got was >2-3 replies (on the most "official" attempt to present a structured/formatted >FAQ-style document asking some fundamental questions for beginners ; apart from that >various questions were asked randomly and most did get answered, but they were a tiny >portion of what was needed for a good devel doc). That was it. > > What docs are there: > > There isn't even an existing "shell" or "skeleton" driver (typical for most types of >projects where they allow "third parties" to develop for them), with the inards >thrown out, so that one can at least get a clue of what components a driver is built >of. Heck, not even a list of files (and their locations and the necessary/needed >inter-dependence). Heck, I know how to bang registers, but DRI is _not_ designed by >me, and it's _not_ clear as daylight even to an experience (non-DRI experience) >programmer. Even after reading all the outdated PI documents multiple times, the >actual implementation details (not the overall idea) was still unclear or fuzzy at >best. > > Oh yeah, there are the infamous "design/devel" documents. They are known as the PI >docs. PI = Precision Insight, the company formed by the core DRI developers who >developed the DRI initially based on these documents (their documents). The documents >were good for the first couple of months of the DRI developement I imagine. Quickly >after, things started to diverge and the docs were full of "this is not implemented" >or "will be in the future" or "incomplete; today we will use bubble sort for this, >quicksort later". That's fine by me, but as long as you tell me _when_ you decide to >switch over to "quicksort" !!! Or even better, when the DRI never switches to >"quicksort" but to something totally undocumented in the PI docs, like "radix sort". >(PS. when I say bubble/quick/radix sort, I am just interchanging these well known >algorithms for DRI/grafix specific algorithms, which don't have such formal names, or >well known names. I personally have not seen any of the above sorting! methods in the DRI :) > > So, letme continue with how I saw the progression of things. So the PI docs diverged >to holly hell from the implementation on many issues. Stuck out of date. By that time >the DRI had already started taking shape, companies like ATI and Matrox (I might be >wrong on all this company stuff as it was of course never public info, since the >contracts were between company and the DRI group/PI/VAlinux later) came into view, >and wanted to contract the PI people to write drivers for Linux. Anyways, so the >contracts came in. The docs served their purpose to start things up, so who cares >about updating them? Nobody. At least that was the view from this side of the >project, because the dates nor the docs changed. Then VALinux buys PI and all/some? >the core DRI developers and the story goes on. > > Point: PI docs are _behemouthly out of date_. Like Mister Iceman found in the Alps >? Like since 1999 ? or 2000 ? Compare this with almost any other "Open Source" >projects/initiative. > > Okay, fine. So the answer on the DRI list is always: read the source. > Notice how easy answer it is: > 1) it's there (the source) duh! > 2) if you can't read it, then you must be pretty lame, coz we can > What can you possibly answer to that? Almost no-one dares (at least not without >some thinking) to say: well I can't make sense of it! > Thank god some people are actualy self-actualized, not overcome by unfounded notions >of incompetence, but rather realistic and very normal learning curve issues, and can >and do say so: code ain't enough! > > Well obviously the very well seasoned X11/GL/3D/grafix gurus (read: all the core DRI >developers) know how to read these sources, especially the DRI sources (guess what? >they wrote them). > > So here come new hackers who really want to get more than 5-6 ( read: 1) 3DFX*, 2) >Matrox*, 3) ATI R128+Radeon*, 4) Intel i8xx, 5) 3DLabs*, forgot any? I am sure not >more than 1-2, at least not during the early 2001 period ) 3D cards working on DRI >(Note: many cards don't work: S3* cards, PowerVR, Kyro*, SiS, a few ATI's, NVidia >cards, and others, this again during the early 2001 period). > > Some developers-wanna-be's had docs, others didn't, others hoped that XFree86 would >help out (DRI not joined with XFree86, no sharing of common resources like docs, >unless u are buddies with those guys, u know, part of the "X-files" :) ), and all >they found in front of them were big walls to climb. To me, this was very reminiscent >of the "old" DOS and Windows days of "closed information" everywhere. Oh blimey, I >am wrong: the source was open!!!! > (like in the DOS days we had disassemblers, how much help they were when working >with API's .. Not! ) > > Well, this situation didn't help much those who wanted to take a first step (don't >look at only me, look at yourself, what are u asking? same things I was) in the >3D/DRI world. > > > Somehow some people managed to overcome some issues, some with help from some DRI >developers, but _never_ with devel. docs. At least I never heard anyone praise such a >thing! Of course overcoming doesn't necessarily mean doing it the proper way. Fixing >bugs or patching almost-working drivers (half-working because the proper DRI >maintainter/coder moved over to a more important job: contracted company drivers). >The proper way being to be able to fully code from start to finish a complete and >fully compliant and working driver. > (AKA: I can go fix a couple driver bugs (usually easily identifiable: ex: ARGB >textured triangle drawing doesn't work) that are laying around 1-2 DRI files, but >that's not comparable in my opinion to writing a full driver). > > Continuing on, I wanted to write drivers from scratch, not fix non-working drivers >(mach64). I learned the hardware. Programmed it, made a user-space mini-driver so I >can develop the code for the hardware, but when it came to doing it in the DRI I was >stuck. I of course read and re-read the PI docs, asked many times what was outdated >and grepped sources looking for the needle in the haystack, but soon realized that if >I was to ask about 10,000 (literally) questions before the driver was complete, then >what the f**k? drop the card, grab a NVidia and f**k the DRI. > > Basically that was my final decision: > I disagree with the implicit DRI ideology. I say implicit because I never heard >anyone preach it, but it sure as hell seems alive around the DRI: > > When I want to help everyone with my effort (provide free 3D drivers for >yet-unsupported hardware), why _should_ I re-invent the wheel (re-learn how a piece >of supposedly VERY important and documented (such as very important projects >_SHOULD_BE) software project), when the wheel should be already well defined and >documented. No. I refuse to waste my time. Not only is my time wasted, but the time >of the whole OSS world!! Because when I could be pumping useful code for them, I am >_reinventing the wheel_. What a waste. So that's why I stopped frankly. > > It wasn't that I didn't want to code; It's what I do. It wasn't that I didn't want >to put the time; I spent tons of hours working on the hardware, and I was planning to >put many hours into the X11/DRI, but for GOD'S SAKE, I am not blind-stupid: I will do >it with a reasonable scientific approach: NOT REINVENTING THE WHEEL (unless >absolutely necessary of course). > > So, there's my take on things. I am sorry if it sounded disappointing or malicious. >I am _really_ disappointed myself from the whole DRI project due to the way things >have turned out. Perhaps I am wrong on somethings, I will accept that, but the >majority of issues I mentioned, I have seen over and over in the mailing lists, >through personal emails with people, and the #dri channel on IRC. I am not alone. > > Finally, I of course do not hate the DRI developers, and I realize what an ambitious >project it is, and do appreciate just like any other user of 3D the efforts they put >into it, BUT, once again I am not blind-stupid: > > there is money involved, so not everyone does it for "free", there is of course love >of the job invovled and I especially appreciate it, but come-on: don't be one-sided. >A well rounded person, project, whatever, has to be optimal or as optimal as _can_ be >(can=lazyness subtracted from the equation), on ALL fronts. > And in the case of Open Source projects, because the development is by default a >decentralized model [ DRI seems like an exception at times :( ], documentation and >guidence is very important. > > Especially on a project as complex as X11+DRI+kernel. We are talking about 3 major >subsystems of an OS (OS in the generic, non-kernel sense). > Once again, we recognize the difficulties of the combo (X11+DRI+kernel), but >come-on, I didn't decide to write a 3D driver because I just managed to kick out a >5-liner Perl script and got a sugar-geek-high. I, as many other prospecting DRI >developers (note: DRI developers, because many of us are developers in many other >projects) do have some solid C, assembly and (grafix) hardware experience. > > Oh well. Enough of this. The more I recall issues the more disappointed I get.. > > > [RANT MODE OFF] > > Finale: > > Anyone: please think about it before (if) you respond to this email. If I am wrong >in something of course I would like to hear it, but my overall feeling of >disappointment in the DRI project is not gonna change easily. If you want to respond, >only do it with DRI devel. docs. Otherwise you are probably wasting your and my time. > > Thanks and good luck to you! > > -- John L. Utz III [EMAIL PROTECTED] Idiocy is the Impulse Function in the Convolution of Life _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
