[Dri-devel] i think i have a functioning FreeBSD SiS 630e/300 agp device. howdo i test it?
hi;
i have reason to suspect that i have successfully hooked up agp in my
FreeBSD kernel.
Why? because agp0 is now attached to a pci id that matches the one that
http://www.yourvote.com/pci/vendors.txt asserts is the agp port on the
SiS630
agp0@pci1:0:0: class=0x03 card=0x80351043 chip=0x63001039 rev=0x21
hdr=0x00
('chip' is the way the pci id called out in FreeBSD land)
this was not the case when i started out on this adventure, so i've hit my
first incremental milestone
ok dri guys, what's the most trivial piece of code that will tell me if
this is actually functional and acting agp-ish?
note that the answer to this question is an important bit of
fundamental dri-porting wisdom!
tnx!
johnu
--
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
[Dri-devel] FreeBSD SiS 630e/300 drm port: who's favorite drm implementationshould i mindlessly copy?
hi again; is there a drm implementation in cvs that is looked upon with favor as being done 'more correctly than others'? is there a drm implementation in cvs that is looked upon with favor as being done 'more simply than others'? note that i have no expectation as to the shape of the venn diagram that describes the intersection or union of these 2 sets. tnx! johnu -- 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
[Dri-devel] how does drm handle chipset specific features in a generalized way?
one last question before i knock off for the nite suppose one has two cards. the first, the FooBarTech VisiBlaster, has special hardware for optimizing the generation of very realistic clouds. the second, the BazGrafix RadiantTurkeyBaster XL6000 AGP 4X Value Edition, has special hardware for optimizing the generation of very realistic hair. how would these get hooked up and taken advantage of? how many layers of abstraction get punctured by these nonstandard features? or am i asking the wrong question because they (every graphics chipset) are *all* non standard? can somebody point me to examples in the code? i'd like to be pointed at examples of graphics generation(the hair and clouds stuff) and examples of hardware operation ( ie turning on DVD decoding or enabling the tv-out signal path ). -- 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
Re: [Dri-devel] DRM/DRI porting guide?
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,
Re: [Dri-devel] DRM/DRI porting guide?
this is actually sufficient for me at this point.
tnx!
johnu
ps: you might think of pasting this part of your response the into the dri
homepage, it would save a bit of bandwidth perhaps:
All OpenGL drivers
are made up of 3 parts:
A DRI aware 2D driver which lives in
xc/programs/Xserver/hw/xfree86/drivers/...
usually in a file *_dri.{c.h}
A DRI aware 3D driver based on Mesa which lives in
xc/lib/GL/mesa/src/drv/...
A kernel module which lives in
xc/programs/Xserver/hw/xfree86/os-support/drm/linux
Go start digging in those directories and asking questions.
or, maybe, it could be part of the standard list bilge that goes at the
end of every email sent back out to the list :-)
On Thu, 17 Jan 2002, Daryll Strauss wrote:
On Thu, Jan 17, 2002 at 02:40:15AM -0800, [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:
Now I'm going to turn this around a bit. You've already seen the answers
from most of us. We're still here, but we're busy with other projects,
and our time is limited. We're all still reading the list and posting
when it seems appropriate.
It's hard work writing docs. It's not a lot of fun (particularly for a
developer) to spend time writing docs.
It is much easier to answer questions than it is to write docs. If
someone takes the initiative to do some digging and ask questions we're
much more likely to respond? Why? Because the scope they're asking for
is more limited. Because they've shown their invested in the
project. You'll find that when you work on open source projects that
lots of people will ask you to give of your time and very few will
contribute on their own.
A good starting point would be to dig through the archives of this list
and collect what's there. It would have a lot of holes, but it would be
a good place to start. I realize it's a pain in the ass, but it's a
start. Has anyone done that? No.
I agree with you that if more modern up-to-date docs were available it
would be easier for other developers to contribute. Pull together what's
on the list already. Ask questions.
Another reasonable complaint is that you need to download too much code
and it takes too long to build all of X. Not everyone has fast machines
and lots of bandwidth. Since the client side OpenGL doesn't change much,
wouldn't it be nice to have a way to compile that separately, so it is
smaller and faster? Yep. Someone do it.
I know I've written this same piece to the list multiple times, but in
order to be more proactive, here's a place to start. All OpenGL drivers
are made up of 3 parts:
A DRI aware 2D driver which lives in
xc/programs/Xserver/hw/xfree86/drivers/...
usually in a file *_dri.{c.h}
A DRI aware 3D driver based on Mesa which lives in
xc/lib/GL/mesa/src/drv/...
A kernel module which lives in
xc/programs/Xserver/hw/xfree86/os-support/drm/linux
Go start digging in those directories and asking questions.
I've given a couple presentations on the DRI, so maybe I can find one of
those to post as well.
Regarding CVS access, Brian, I get email from people, and I talk to
those people that have shown some investment. I've only added one or two
people. My stock answer when asked is that you should submit a patch or
two before we give access. Now one has. For the few people that have
shown some code or even a good understanding, they've turned me down
saying they're too busy.
- |Daryll
--
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
[Dri-devel] DRM/DRI porting guide?
greetings; i am interested in writing the bits required to get dri working on the SiS 630E (which evidently contains an SiS300 and SiS 301, among other things) on FreeBSD. It's my understanding that this chipset is supported under Linux, but i havent poked around in the tree yet. is there such a thing as a porting guide? i have glanced at docs ref'd at http://dri.sourceforge.net/doc/DRIintro.html the docs are kinda old. and the one that seems most pertinent: DRICompile.html, is an invalid link. now, i understand the basics: 1. Kernel Support 2. Make drm aware of the kernel support. shoulnd't this be all? isnt it independent after that? that's what the drm is for? so, if there is a hardware porting guide beyond Use The Source Luke! i'd love to take advantage of it. is there a porting harness? ie, a stub that i can use to poke at the kernel support so that i can make sure that it does what it's supposed to? if the answer to both is no, cool. just let me know so that i done waste time googling for something that doesnt exist ( ie: OpenGL porting guide gives me lotsa links about how to move your apps from 'ClosedGL' to OpenGL but i obviously am interested in the other end of the pipeline! ) tnx! johnu -- 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
