[Dri-devel] Card & Motherboard / Chipset directory.
How about a directory / database of cards and the motherboards / Chipsets that are known to work, preferably with some info on how they were gotten to work eg distro & patches applied. IMHO the biggest problem people seem to have is incompatibilities between chipset and graphics card, and if you can rule that out by seeing that it (your set-up) has worked for someone else and how they got it to work, you'd be more than half-way to a running system. Liam "IT depends" ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon VE? (Carl Busjahn)
Howzit? > If you dont care about the extra head then get the Radeon LE > best bang for buck Radeon (possibly / probably NVidea's options > as well) card available. > > > Thanks for the information, it was very helpfull., I'm sorry If I > > offended anyone by saying radeon is faster than Gf2 mx400, though it > > is :-) You might want to research your hardware before you say > > something like a radeon doesn't have T&L... > > Yes a Radeon does have T&L but I beleive it has been removed > from the Radeon VE along with a texture pipeline (only the radoen > VE has been crippled like this) it furthermore has a 64bit DDR link > to its Vid Card Mem leaving it with as much bandwidth as the > Radeon SDR 32MB (which I have). Again the Radeon LE is my recomendation it's basically a Radeon DDR 32MB. btw is this supposed to be on the devel list? Liam "IT Depends" ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Sorta OT: Congrats on DRI success & Block Diagram & Feature Checklists (Doc) proposals.
Howzit? First let me thank you for DRI bringing 3D to my Linx box, its been a while but the wait was worth it. Mandrake Linux obviously follows DRI. I have the following proposals regarding the Documentation of the DRI project. Firstly a block diagram showing how the the various aspects of 3D on Linux fit together. ie how DRI, XFree86 4.1, the window manager, Linux Kernal, OpenGL, the actual drivers for various graphics chipsets etc fits together. This I feel would make it easier to see the big picture of 3D accelleration on Linux, making it easier for people to see where things are going wrong. Secondly a Feature Checklist page for each graphics chipset / graphics card (where apropriate) showing the HW features of each card and whether or not they are implemnted in DRI / driver or the status of said function. I am willing to generate these html pages for the DRI website provided I am provide with plaintext (preferably (g)zipped) stating the name of the graphics chipset, its manufacturer, a list of its features, and the status of each of these features. You will receive a nicely formatted, simple, indexed, html page in return for each chipset / card with a hopefully easy to read / understand tabel showing the features and their status. I'm not looking for flames but the last time I checked the DRI website it had a list of cards and the status of their support, but no mention of features - I feel that this would represent an improvement. cheers Smitty ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Graphics Chipset / Card Feature Lists required.
Howzit? (How is it going with you?) Been talking with Frank Worsley about adding some more documentation to the DRI site. In order for me to write some html documentation on the status of DRI's support for the features of each card / chipset I will of course need to know what exactly are the features of all the cards / chipset's that DRI supports. And of course the status of these features in terms of DRI support. If anyone could provide this information or knows who I should contact, reply. I am subscribed to the dri-devel & user but please CC me, otherwise I might miss your post in the digest. cheers Liam interesting site: http://rhodesian.server101.com/index.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Voodoo5 SLI / AA -> Win32 Dissasemblers
Hej! There are plenty of free dissamblers but you will get x86 assmbler code (but hey that's better than binary) there are even some that are willing to convert some of that assembler to "pseudo" C. cheers Liam PS If anyone wants to help me aquire (I'll do the rest) documentation of DRI supported graphics chipsets features please contact me. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Athlon/Kt133/Radeon QD system locks with > 1GB ram
> Hmm.. Another thing to check - are you sure your power supply is > adequate ? Radeon chip has a fan on it for a reason. Actually the fan is there to make the Radeon look faster, it runs cool at the .18 process on wich it was manufactured. Power draw I wouldnt know, then again I run my radeon / Duron system off a 235watt ps. cheers Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI / IHV Contact people.
Howzit? Maybe a bit of a strange question, but I think it should be asked. Does the DRI project have a contact person at each of the IHV's? Specifically ATI, Nvidia seems to be more of a closed source house, and 3dfx is now defunct. This just strikes me as an extremely useful thing to have in terms of comunication, documentation, concerns, queries, etc that either party may have. One other thing, does anyone have any recomendations on how I can obtain information regarding the capabilities / features of graphics cards / chipsets, and their status under DRI. Bear in mind that I am sitting in the middle of nowhere at the end of a 56K modem, in a country with a telecomunications monopoly, and I have to pay the phone bill. cheers Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Card features supported list
Howzit? I bothered ALexander Stohr and got to working on the features supported list. This is a basic template / example feature table. Things that would so far already be differnet in a "release qualiteit" doc could include: a Key explaining anything needing explaining. Links to other projects that provide support for certain features (gatos) A section of the table dealing with components that are optional on a card eg tv-out, video capture, etc. Problems encountered: 1. Knowing what is relevant. So far this information comes from the ATI spec sheets, and obvioulsy it is difficult for me to know what is relevent architecture and what is marchitecture or irrelevent (ie is supported function in hw whether inplemented in DRI code or not). Knowing the status of various features. 2. I have a Radeon 32MB SDR OEM, it accelerates my 3d apps, my knowledge of which of its features are implemented in DRI is sketchy at best. Posisble solutions: Spent more than 10 minutes on the html would improve quality. Getting sugestions from what people would like to see included would help far more. 1. I could either keep the table very small, and have people request things to be added, or make it contian anything that could possibly be relevent, and remove things that turn out to be irrelevent (again at the request of people in the know). 2. This I need all the help I can get. DRI developers probably know exactly which features are done, which are being worked on and which are not. I'm pretty sure Vladimir knows what the status is regarding the tv / vivo functionality. cheers Liam rad.html Description: Binary data
[Dri-devel] Downloadable Radeon TCL binaries (20020409) work with LM8.1.
Howzit? System specs: HW: AMD 751/756 (750 / Irongate) mother-board (GA-7IXE4) Radeon 32MB SDR vid card Duron (Morgan) CPU SW: Linux Mandrake 8.1 fresh install install source RPM (kernel 2.4.8 Xfree 4.1 with 3d acceleration) download: radeon-20020409-i386-Linux.tar.gz run install script as root No problems reported startx no problems Although to get it to "take" a shutdown (reboot) seems to be neccessary. Nice work, Frank Worsley & Alan Hourihane on the install script, Tungsten Graphics for the T&L for the Radeon and all the rest who work(ed) so hard on the DRI for Radeon. cheers Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] New cards (GPU's) from old card makers? DRI support?
Howzit? First there was the merger announcement by Creative and 3DLabs and the disclosure of their upcoming 76 million transistor GPU this holiday season. Then SiS surprised us at CeBit with their new SiS330 series of DirectX 8-compliant 3D accelerators. As if that wasn't enough, rumors of Matrox's return to the 3D gaming segment began to surface. And who could forget all the speculation -- and seemingly more -- surrounding the Imagination Technologies, STMicro, and VIA triangle? But just when you thought things couldn't possibly get any more interesting, another old player in the industry, Trident, has re-emerged with a new DirextX 8.1 3D graphics accelerator. So up to five new GPU's / architectures which leads to the obvious question(s); Are there any plans to implement drivers for these cards? Have any of the manufactureres made an approach or started asking questions about DRI? Or is this all completely off the radar screen at the moment? I love competition. cheers Liam P.S this had better not degenerate into another (near) flame fest carrying on about deferred / software / direct (emidiate) rendering, where people start mixing up their hardware concepts. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon Card Features DRI Checklist.
Howzit? Here is my "alpha" list of features I would apreciate feedback on what should be on the feature checklist, the grouping and most importantly the *status* of these features. (I deliberately included everything bar the kitchen sink that I can find so that I dont have to add them in future. Which means that some of it is marketing blurb.) This is about as simple as I can make it. Simply put Yes / No, HW / SW, or any other apropriate comment next to the feature. Feel free to point me to any existing list(s) indicating the level of suport that these features currently enjoy. ATI R100 (Radeon) = Anti-aliasing = Full Screen Line & Edge Double Buffering --- Filtering = Anisotrophic texture --- Bilinear --- Trilinear -- KTX buffer region extension Key Frame Interpolation Gamma Control -- Guard Band Clipping Mapping === Bump --- Cubic Envionment --- Dot Product 3 -- Dual-Parabloid - Emboss - Mip Perspectively Correct Texture -- Page Flipping -- Single-Pass Multi-Texture -- System Memory Blits Superscalar Rendering -- Specular Highlights Table Fog -- TCL Back Face Culling -- TCL Hardware --- Twin Cache Architecture Texture Units per pipeline (3) - Triangle Setup Engine -- True Colour Rendering -- Texture === Cache -- Compositing (De)Compression Vertical Sync -- Vertex Skinning Volume Textures W Buffer --- W Fog -- Z Plane === Z Fog -- Z Mask - Fast Z Clear --- HierachicalZ --- HyperZ - Z-buffer: 16, 24, 32 bits -- 8 bit Stencil -- Effects? Fog Effects Texture Lighting --- Video Textures - Reflections Shadows Spotlights - LOD Biasing Texture Morphing --- Video Features == Adaptive De-interlacing - Motion compensation - IDCT (sp?) -- Driver Optimisations 3DNow! - SSE SSE2 --- ciao Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon Card Features DRI Checklist. Clarifications part 1
Howzit Ian? Thanks for your response. > I'm not the most qualified to answer this, but I think most of the more > qualified people are pretty busy adding some of these features. :) Noted. But if yours is the only response and / or there are no differing answers guess what, you will become correct (most qualified) by default. What exactly do you mean? seems to have a suspiciously high corelation with the marketing blurb features. In other words it's from ATI's brochures on their various cards. I'll try and clarify. > ATI R100 (Radeon) > = > Mapping > === > Bump --- No. Will be possible once (if) the > extension is added to Mesa. By this I am >assuming you mean environment bumpmapping. Yes, Environmental bumpmapping. > Emboss - What exactly do you mean? If you are > refering to Nvidia's NV_texgen_emboss >extension, then it will likely never be >supported due to Nvidia's IP. It was in ATI's brochure, I grabbed it out of this brochure point: * Emboss, Dot Product 3 and Environment bump mapping (that's letter for letter, same layout - you decide please) Please see this ATI page on how to do it in HW & with OpenGL http://www.ati.com/developer/sdk/RadeonSDK/Html/Tutorials/RadeonBumpMap.html#EMBOSS PC Paradox: (http://www.pcparadox.com/Editorials/BumpMapping/Bump2.shtml#emboss) Emboss Mapping The real name for emboss mapping is Multi-Pass Alpha Blended Bump Mapping. So as you can see, "emboss mapping" sorta stuck as the name. (and the acronym MPABBM really didn't seem to fit either :) Well there is a reason that emboss mapping has that weird funky name. The name is actually a great description of how this technique gets around the whole lighting problem I discussed on the previous page. But first I'd like to start off by saying that emboss mapping was the first method used to simulate bump mapping in real time, and thus was lacking in many ways. These small problems made emboss mapping look dullish and took an unnecessary amount of time for such a simple rendition of the effect. Ok, now emboss mapping achieves the bumpy effect by creating a monochrome version of the texture map being "bumpified" and then applying it to the polygon and shifting it slightly. To help you visualize this effect, think of a drop shadow effect, where lettering on a page has a black set of the same lettering offset just a little bit. Drop shadowing and emboss mapping are essentially the same. In emboss mapping once the monochrome version of the texture has been shifted, it is then cut and blended with the original and applied to the texture, giving it the bumpy effect. There are many limitations to emboss mapping, and here are a few. Emboss mapping only supports polygonal objects and can not be applied to a volumetric or multi-lit surfaces. Also Emboss mapping is limited to lighting coming from a certain angle (45 to -45 degrees). It can not handle more than one height of bumps because the bumping has to be uniform across the entire object. And most importantly, Emboss mapping can really slow down your CPU because of all the converting and FPU calculations it has to do to shift a texture perfectly. > System Memory Blits What exactly do you mean? I'll dig up a decent definition for you, it is however from DX. > Superscalar Rendering -- What exactly do you mean? Perhaps they describe the fact that the R100 renders as super-scalor rendering because it has two pipelines? >From Lost Circuits: (http://www.lostcircuits.com/video/atifury/3.shtml) SuperScalar Rendering Engine The RAGE 128 uses two graphics pipelines working in concert to process two pixels each clock cycle. This kind of parallelism is typical of a superscalar architecture. Consequently, the two RAGE 128 engines which render the scene in parallel, is referred to as a Super Scalar Rendering Engine. The speed of rendering is very close to twice that of single pipelined graphic chips. > Twin Cache Architecture What exactly do you mean? >From PC Insights: (http://www.pcinsight.com/reviews/aiw128/aiw1283.asp) Twin Cache Architecture Of all the 3D features of the Rage 128 chip, the Twin Cache Architecture seems to stand out the most because it is unique to the Rage 128. The Rage 128 uses an 8KB buffer to store texels that are used by the 3D texel engine. In order to improve performance even more though, ATI engineers have also incorporated a 8KB pixel cache used to write pixels back to the frame buffer. >From Lost Circuits: (http://www.lostcircuits.com/video/atifury/3.shtml) Twin Cache Architecture Like microprocessors, the on-chip cache in graphics chips is growing dramatically. The RAGE 128 has not only incorporated significa
[Dri-devel] Radeon Card Features DRI Checklist.
Howzit? Here is my "beta" list of features I would apreciate feedback on what should be on the feature checklist, the grouping and most importantly the *status* of these features. I would like a bit more input on the status of the features, otherwise I am going to use what I have and make the final ascii version / html table which will be from contributors (below) and some editing & formatting by me for comment to catch the bugs. This is about as simple as I can make it. Simply put Yes / No, HW / SW, or any other apropriate comment next to the feature. Thanks for their help and input to: Ian Romanick <[EMAIL PROTECTED]> Michael <[EMAIL PROTECTED]> Jens Owen <[EMAIL PROTECTED]> Added: Pixel shader Programmable texture blending modes - Projective Textures-- Changed: Mapping === Environment Bump --- Dot Product 3 Bump-- Emboss Bump Clarifcations, see: Re: [Dri-devel] Radeon Card Features DRI Checklist. Clarifications part 1 ATI R100 (Radeon) = Anti-aliasing = Full Screen Line & Edge Double Buffering --- Filtering = Anisotrophic texture --- Bilinear --- Trilinear -- KTX buffer region extension Key Frame Interpolation Gamma Control -- Guard Band Clipping Mapping === Environment Bump --- Dot Product 3 Bump-- Emboss Bump Dual-Parabloid - Cubic Envionment --- Mip Perspectively Correct Texture -- Page Flipping -- Pixel shader --- Programable texture blending modes - Single-Pass Multi-Texture -- System Memory Blits Superscalar Rendering -- Specular Highlights Table Fog -- TCL Back Face Culling -- TCL Hardware --- Twin Cache Architecture Texture Units per pipeline (3) - Triangle Setup Engine -- True Colour Rendering -- Texture === Cache -- Compositing (De)Compression Projective Textures Vertical Sync -- Vertex Skinning Volume Textures W Buffer --- W Fog -- Z Plane === Z Fog -- Z Mask - Fast Z Clear --- HierachicalZ --- HyperZ - Z-buffer: 16, 24, 32 bits -- 8 bit Stencil -- Effects? Fog Effects Texture Lighting --- Video Textures - Reflections Shadows Spotlights - LOD Biasing Texture Morphing --- Video Features == Adaptive De-interlacing - Motion compensation - IDCT (sp?) -- Driver Optimisations 3DNow! - SSE SSE2 --- Liam "it depends" ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Card Features DRI Checklist. (Ian Romanick) & Spam
Howzit Ian? First off, dankie. Noted, used, and added a few mechanisms to deal with: I think Nvidia proprietary > Texture > === > Cache -- Automatically supported by the hardware. Not according to Michael Ntlworld, and he backed it up. Oh and I won't post such a massive email, I'll use links. btw the list is now up on the (card) status page of dri.sourceforge.net. One last thing, is that there is a whole list of 11 items of which status is listed as Unsure of Status. Once finished (up to date at least), the fact that this list is created I can get moving on the Rage 128, and then the Mach 64 feature lists. Spam About the spam we've been getting on the list I've heard good things about SpamCop: http://spamcop.net I believe that you need the email headers and I'm on the DRI *digest* option... Liam "it depends" ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Card Features DRI Checklist. (Damien Miller)
Hwozt damien? > > btw the list is now up on the (card) status page of dri.sourceforge.net. > > It would be really good if the status included what features are supported > by the hardware. This may make it easier for interested parties to jump in > and pick up pieces that they want to work on. I'm not sure I follow (I might but I'm not sure) could you be more specific. The list as it stands has the features of the Radeon, with the DRI status of each. Let me explain how I compiled the list: Tried asking the developers for features, no response which is probably a good thing, coding should be their first priority. (see archive) I let it rest for a while then came up with this plan of action. Got settings from latest ATI drivers (Win98) via config screens & registry settings. Got features from ATI brochures. Googled - not much help, (try it). Drew up my list, ordered it, posted it, got some reponse, compiled it and finalised it and the status, created and hand tweaked the html table, sent it to Fank. >From that you can see that DRI only became involved late in the process. You are most welcome to suggest features to be added to the list (see archive) as well as answer the Unsure of Status features. Liam "it depends" ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Website
Howzit? > 1) I *NEED* info about what cards have what features supported by DRI, > like the radeon driver does already. Don't we all. > 2) rehash the voodoo5 glide compilation to a generic voodoo guide Can not help here. > 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 ? * > 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? * > 5) Can someone with a nice package re-draw the DRI flowcharts? the > Precision Insight ones look like Fischer Price 'my first flowchart'... Will give this a go, but be warned of two things. One I will probably get some things wrong which will need to be fixed / > pointed out by a developer. It is unlikely that it will look anything like Fischer Price I think that we still don't have that here. 6) What is required in order to produce drivers for other architectures - If people tell me this, I will add it to the 'help us' section of the site. Perhaps someone could set up a mailbox that people wanting support for other architectures could send messages to, so that demand can be guaged. * * I support making lists of these things and am also willing to make them if I am supplied with the information, even if not for the exact reasons that you want them for. DRI documents: -- > 1. Introduction to the Direct Rendering Infrastructure - Brian Paul, August > 2000 > http://dri.sourceforge.net/doc/DRIintro.html > > 2. Dri term glossary. http://dri.sourceforge.net/doc/glossary.html > > 3. Data flow diagram > http://dri.sourceforge.net/doc/data_flow.jpg > > 4. Control flow diagram > http://dri.sourceforge.net/doc/control_flow.jpg > http://dri.sourceforge.net/doc/control_flow_poster.jpg. > > 5. A Multipipe Direct Rendering Artitecture for 3D. Jens Owen, Kevin E. > Martin. September 1998 > http://dri.sourceforge.net/doc/design_high_level.html > > 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 > > 7. The Direct Rendering Manager: Kernel Suport for the Direct Rendering > Infrastrucure. Rickard E. Faith > http://dri.sourceforge.net/doc/design_high_level.html > http://dri.sourceforge.net/doc/drm_low_level.html > > 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 > > 9. A Security Analysis of the Direct Rendering Infrastructure. Rickard E. > Faith, Kevin E. Martin > http://dri.sourceforge.net/doc/security_low_level.html > > 10. DRI Extension for supporting Direct Rendering Protocol Specification. > Jens Owen, Kevin Martin > http://dri.sourceforge.net/doc/dri_extensions_low_level.txt If anyone wants a particular document updated let me know. Liam "it depends" ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI website updated
Howzit? > I've updated the Documentation page of the website. I've copied all the > docs from Precision Insight's "Insight" page and put them onto our site. > The link to the "Insight" page has been removed. So all the docs relating to DRI are on dri.sourceforge now? If not why not, centralisation on a small scale is usually a good idea, obviously links are in some cases acceptable. > 1. Read through the FAQ comments and delete old/wrong/off-topic posts. > There is a FAQ admin page that lets you delete comments. Anybody > interested in doing this let me know and I will tell you how. This does > not really need to be done, but it might be a good idea to clean up the > comments. Did José do this? IIRC he did. > 2. Regarding the above, the FAQ admin page could be improved. Right now > every comment has to be deleted by clicking a button. It would be nicer > if you could mark comments to be deleted (via checkboxes) and then press > one big button. Anybody that knows PHP and wants to tackle this, let me > know. It would make task 1 much easier. Not for me. Anyone? > 3. It might be nice to put up a "Links" page with links to related > projects/companies, such as: Xfree86, Mesa, FbDri, Precision Insight, > Tungsten Graphics, Has this been done? Else I'll do it / update it whatever. Link submissions? > 4. On the "About DRI" page it still says that the "principal developers" > of the DRI are employed by VA Linux and a bunch of other VA Linux stuff. > Anybody who can come up with an updated and nice sounding paragraph to > replace that, send it in and I will put it up. What would you like it to say? I'll write something but exactly what depends. I know something eg Tungsten Graphics would be apropriate but what else? Principal developer submissions? > 5. Liam ([EMAIL PROTECTED]) is working on putting together a better > status page with a card/chipset feature checklist. I am sure he could > use some help, so anybody intersted in that can help him out. Yes I have / am, and about those other ATI cards ie r128 and mach64 they have pretty much the same feature list as the Radeon, a few less maybe but certainly not (many) more. Feature / status submissions? Liam "it depends" ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI documentation
Howzit? >> There are a few other documents on the Insights Page that I didn't >> bother duplicating on the DRI page. It might be a good idea to do this >> now, since the Insights Page might not be around forever. Would that be >> ok with VA Linux/Precision Insight regarding copyright issues? > I don't work for VA Linux anymore, so I can't give you any specific > permissions--however, I will point out that the original low level > design documents on that page are under the following license: > > "Copyright =A9 1998-1999 by Precision Insight, Inc., Cedar Park, Texas. > All Rights Reserved.=20 > > Permission is granted to make and distribute verbatim copies of this > document provided the copyright notice and this permission notice are > preserved on all copies." > > So, you can copy them to the DRI site--but we can't modify them. Still, > they might be useful to new developers trying to get some idea on early > design decisions. -=-=-=-=-=-=-=-=-=- Now this poses a wee bit of a problem for any attempts to update theses kinds of documents doesnt it? Or does it? If I read it, gain an understanding of the DRI system / infrastructre and use my newfound knowledge to create my own document from scratch that's ok right. Problem is this isnt very abstract, and I'm not going to gain an encyclopeadia type knowledge of the subject matter and create a new original / vastly different document, its going to be what it is, an update of the original. Think if I /we bother them nicely they'll let me use their original as a base / template? I have no problem putting: "Orignal by: Precision Insight, Inc., Cedar Park, Texas." or something to that effect but: "Copyright =A9 1998-1999 by Precision Insight, Inc., Cedar Park, Texas. All Rights Reserved.=20 Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies." is IMHO a bit too much, especially as they dont seem to be doing any maintainance. Ideas, comments? Liam "It depends" ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Website (Michel Dnzer)
Howzit? > On Fri, 2002-05-24 at 19:54, Smitty wrote: > >=20 > > 6) What is required in order to produce drivers for other architectures > > - If people tell me this, I will add it to the 'help us' section of the > > site. > > Do you mean other architectures as in other OSs or as in other processor > architectures for an already supported OS? The former depends on how > similar that OS is to Linux, the latter on how similar that processor > architecture is to the ones already supported. In general, the latter > will be much easier because there are relatively little dependencies on > the processor architecture and the most important kinds are already > supported. Probably both. Although other OS's would probably be BSD or *nix. & the hardware that supports eg a Radeon would probably either have its own drivers or would be running Linux / BSD / *nix. cheers Liam ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Understanding the flow of data to the Graphics hardware.
Howzit? I would like to confirm my understanding of the various data paths between applications (both direct and indirect rendering) and the graphics hardware. First I have the path of 3D data between the 3D direct rendering program and the graphics hardware which is pretty simple. Direct rendering program (3D stuff) | Direct rendering (3D data) | 3D data | Graphics hardware Second I have the path of 2D data between the 3D direct rendering program and the graphics hardware. Here I would like some clarification where I have question marks. Direct rendering program (2D stuff) | X protocol encode (2D data) | 2D data | ? X-server ? ? Decode and dispatch ? ? DDX Driver ? | 2D data | Graphics hardware Third I have the path of 2D data between the 3D indirect rendering program and the graphics hardware. Again I would like some clarification where I have put question marks. Indirect rendering program (2D stuff) | X protocol encode (2D data) | 2D data | ? X-server ? ? Decode and dispatch ? ? DDX Driver ? | 2D data | Graphics hardware Lastly I have the path of 3D data between the 3D indirect rendering program and the graphics hardware. Again more clarification where there are question marks. Indirect rendering program (3D stuff) | OpenGL encode (3D data) | 3D data | ? X-server ? ? Decode and dispatch ? ? DDX Driver ? | 2D data | Graphics hardware Are the, ? encode , lines "processes" ie they create / produce the 2D (X Protocol encoding) or 3D (OpenGl encoding) data? The main thing I want to know is what happens between the Encoding and the Graphics hardware. Please point out any errors. This information will be used as part of the documentation for DRI in the form of a flow chart. cheers Liam ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Re: [Dri-devel] Understanding the flow of data to the Graphics hardware.
Howzit Jens? > Did you see the flow chart at > http://dri.sourceforge.net/doc/control_flow_poster.jpg Yes, and I've worked through it. I am referring to: http://dri.sourceforge.net/doc/data_flow.jpg IMHO it doesnt make it any clearer what happens once the 2D & 3D data arrives at the X Server (with its Decode & Dispatch, DDX Driver, Mesa Software Renderer). Yes I can see that the data arrives at the X server, something happens to it and then it leaves (transformed). What happens in there is what I'm after. What is the sequence in those various paths through the X Server which I laid out in my previous email. Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Links Page Submissions
Howzit? A links page was requested and this is what I have so far, have I missed anything, is anything unneccessary? If so I think you know what to do about it. Links to Projects & Companies related to DRI: Chromium Project (The) http://chromium.sourceforge.net FbDri http://fbdri.sourceforge.net GATOS General ATI TV and Overlay Software http://gatos.sourceforge.net/ Mesa http://www.mesa3d.org Tungsten Graphics, Inc. http://www.tungstengraphics.com Utah-GLX http://utah-glx.sourceforge.net VA Software http://www.valinux.com XFree86(TM): Home Page http://www.xfree86.org Xi Graphics Home Page http://www.xig.com Graphics Card Manufacturers: 3dfx http://www.3dfx.com 3Dlabs http://www.3dlabs.com ATI http://www.ati.com Intel http://www.intel.com Matrox http://www.matrox.com NVidia http://www.nvidia.com Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Understanding the flow of data to the Graphics hardware. -> DRI Awareness
Howzit? First off I really should change my Subject line more often. > > I've been thinking, dangerous yes I know, but DRI (desperately) > > needs people willing to program C for the drivers or look for > > bugs etc -right? > > We do need people...we're not desperate. It's amazing what a few *good* > people can do. Brackets are wonderful. A few good men > > Well I am a student and there is a Department of Computer Science > > in the Faculty of Science, and these guys program C(++) etc so > > maybe I should advertise the existance of DRI & its need for > > programmers on the computer science forums? > > Be carefull not to over estimate the ability to program in 'C'. The > real key here is having a strong interest in Graphics Technology. > Highly motiviated individual who don't program can still be helpful in > testing, giving user feedback and helping with documentation. > Programmers however need to go much deeper than knowing 'C'. Having a > strong understanding of systems programming and a fundemental idea of > how the graphics pipeline works is critical. We would like to find more > developers with that kind of background, or strong desire to develop > that kind of background. I wasn't but of the type of people who would be interested in this sort of thing, a large percentage of them program. > In the end, I would recommend you make more people aware of our project > and the kind of work we do. However, I would avoid just recruiting > "programmers". > > Does that make sense? Perfectly. IMO the awareness of the DRI project is quite low, even amongst Linux users out here. I'll just mention it casually, whenever the subject comes up ie Graphics drivers / Open source projects / etc btw comments on control flow? Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
Hei Jens Remember this? +---+ | X11/OpenGL Based Application| | (Using 3D Direct Rendering) | +--++ | OpenGL Library | XLib | | +++ | | | GLXLib | | +-+---++| | |Mesa | DRILib || | | | +++---+ +-+ | Protocol Encode | | Mesa Driver | | | | +-+---+-+ | | DRM Lib || +---+-+| | | | V | | | X Transport V V V MMIO IOCTL SHM Well I'd like to explode it. This is what I have so far: +-+ | X11/OpenGL Based Application | | (Using 3D Direct Rendering) | +-+ | | V V +--+ ++ | OpenGL Library | | XLib | +--+ ++ | | | | | | | V V | | | +-+ | | | | GLXLib | | | | +-+ | | | | | | V V V | | +-+ ++ | | |Mesa | | DRILib | | | +-+ ++ | | || | | | || V V V || +-+ || | Protocol Encode | || +-+ ||| V|| +-+|| | Mesa Driver ||| +-+|| || || |V V| | +-+ | | | DRM Lib | | | +-+ | || || || || || |V || | X Transport VV V MMIO IOCTL SHM Comments? One thing that I would like to be able to show is, when you have one line going into a box and two lines coming from it, is a branch occuring or is it an either or situation. ie a choice is made and only one path is taken. I've attached the latest WIP of control_flow.png to help show this. RM = Resource Management or = 1 of these 2 paths are followed & = both of these 2 paths are followed 2D = 2D commands & data 3D = 3D commands & data lines in columns indicate individual paths while, lines not in columns are agregations of paths. eg's in my bit of exploded ascii art and the X Server. This becomes somewhat of an issue when you have multiple line entering and leaving a box, so if the lines should match up and don't or vice versa - let me know. DRMLib whats the differnce between the one in the X Server and the one in the 3DDRP? They both talk to Kernel & SAREA (SHM & IOCTL). Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] missing file - cntrl_flow.png
I've attached the latest WIP of cntrl_flow.png to help show this. Wasn't paying enough attention. Liam it depends cntrl_flow.png Description: Binary data
Re: [Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
Howzit Jens? 3 Parts to this email. 1.) MK II: _ \ +-+ | | X11/OpenGL Based Application | | | (Using 3D Direct Rendering) | | +-+ | | || V V| +--+ ++ | | OpenGL Library | | XLib | | +--+ ++ | | | | | | | | V | | Application | | +-+ | |--User | | | GLXLib | | |Process | | +-+ | | V | | | | | +-+ V V | | | | OpenGL| ++ | | | | Renderer | | DRILib | | | | +-+ ++ | | | || | | | | | |V V V V V | | +-+ +-+ | | | DRM Lib | | Protocol Encode | | | +-+ +-+ | || || _/ VV VV MMIO IOCTL SHM X Transport > I would say in the most common case (single thread, single 3D context) > there is only one arrow between the application and a combined > Xlib/OpenGL box. This single arrow can be thought of as the primary > system:display.screen connection, to use X11 DISPLAY semanitics. Which is the equivilent to the top two arrows in this diagram. OpenGL Lib & XLib are just shown seperately. 2.) > > One thing that I would like to be able to show is, when you have one line > > going into a box and two lines coming from it, is a branch occuring or is > > it an either or situation. ie a choice is made and only one path is taken. > > It depends. There are a large number of actual entry points in each of > this libraries. Some entry points may never pass data along. Others > may use one or both of the paths. Doesn't it just. But it worked out ok for the X Server internals so I'd like to do it here. > > I've attached the latest WIP of control_flow.png to help show this. > I did *not* receive an attachment. But you've seen it now... > > RM = Resource Management > > or = 1 of these 2 paths are followed > > & = both of these 2 paths are followed > > 2D = 2D commands & data > > 3D = 3D commands & data > > > > lines in columns indicate individual paths while, > > lines not in columns are agregations of paths. > > > > eg's in my bit of exploded ascii art and the X Server. > > > > This becomes somewhat of an issue when you have multiple line entering > > and leaving a box, so if the lines should match up and don't or vice > > versa - let me know. > > I'll probably understand this question better after I see your WIP. Yup it's all part of the same question. 3.) > > DRMLib whats the differnce between the one in the X Server and the > > one in the 3DDRP? They both talk to Kernel & SAREA (SHM & IOCTL). > > Functionally they are identical, i.e. the same source code. The only > distinction, and it's not critical to the diagram, is the DRMLib used in > the X Server needs to be a dynamically loaded X module. The one used by > the 3D client driver is statically linked into the 3D client driver's > shared library. > > Hmmm, thinking about this some more, I wonder if the staticly linked > DRMLib will be a problem if we ever try to support direct rendering to > multiple heads. If each head required a different driver, then the drm > symbols would colide. Sorry, just thinking out loud... Assumptions: a) The DRM Lib in the X Server gets its inputs from the RM path which comes via the X Transport between it and the 3DDRP. b) In the 3DDRP (aplpication's user process) everything except XLib has either direct or indirect access to the DRM Lib in the 3DDRP. c) Now by looking at XLib in the 2D only Program and in the 3DIRP it is not concerned with the RM path / the DRM Lib in the X Server. Would it not be better (simpler / faster) to do resource management via the DRM Lib in the 3DDRP than via the DRM Lib in the X Server? Whether it would or whether it would not and why would be useful, I think it is a reasonable question even though it has assumptions. Liam it depends N2S: hw / sw accel. * (in)direct Rendering explane dif's. ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tuxkart, and bug reports.. (David Willmore)
Howzit? > I see that there is a very active development community and three big projects > in the works (radeon, radeon T&L, and mach64). Yes I've slowly realise that this is what goes on in the DRI project, a thought has been rattling around in my head of late of a simple list of who is working on what project and more specifically what they are doing eg fixing bug xyz, adding feature abc, etc. That might make it easier for new developers who come along and say I want to help on xyz / abc and he can be referred to some one relevant. Might be a good idea to keep the list private, to prevent developers being swamped by email, bug reports, etc. Hey Jens? > The re-write of the web pages should > help, as well. The recent discussion on what the data/call flow charts should > look like--if captured on the web site--would be an invaluable resource to get > more 'power users' bootstrapped. That's the plan it is progressing, although the guy doing the website itself is a little busy at the moment. > Update the web site. Having an almost undocumented web page with nightly > tarballs or anon CVS access is pretty user hostile. This is all part of the plan. > Oh, and I have an nVidia Riva ZX that nVidia doesn't care to support. Anyone > want it? Nice little 8M AGP card looking for a loving developer... ;) A loving developer - that defnitely counts me out. Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
> > 1.) MK II: > > _ > > \ > > +-+ | > > | X11/OpenGL Based Application | | > > | (Using 3D Direct Rendering) | | > > +-+ | > > | | | > > V V | > > +--+ ++ | > > | OpenGL Library | | XLib | | > > +--+ ++ | > > | | | | | > > | | V | | Application > > | | +-+ | |--User > > | | | GLXLib | | |Process > > | | +-+ | | > > V || | | | > > +-+ VV | | | > > | OpenGL| ++ | | | > > | Renderer | | DRILib | | | | > > +-+ ++ | | | > > | | || | | | > > | V VV V V | > > | +-+ +-+ | > > | | DRM Lib | | Protocol Encode | | > > | +-+ +-+ | > > || || _/ > > VV VV > >MMIO IOCTL SHM X Transport > > > > > > > I would say in the most common case (single thread, single 3D context) > > > there is only one arrow between the application and a combined > > > Xlib/OpenGL box. This single arrow can be thought of as the primary > > > system:display.screen connection, to use X11 DISPLAY semanitics. > > Which is the equivilent to the top two arrows in this diagram. > > OpenGL Lib & XLib are just shown seperately. > > Okay, but this is another example of where the number of arrows is just > plain confusing... nice play on words. First I want to get all the facts then I'll make it less plain and less confusing. It'll also be less confusing when I implement the alignment i was carry on about earlier. > > 2.) > > > > One thing that I would like to be able to show is, when you have one line > > > > going into a box and two lines coming from it, is a branch occuring or is > > > > it an either or situation. ie a choice is made and only one path is taken. > > > > > > It depends. There are a large number of actual entry points in each of > > > this libraries. Some entry points may never pass data along. Others > > > may use one or both of the paths. > > Doesn't it just. > > But it worked out ok for the X Server internals so I'd like to do it here. > > The X Server case is a very cut and try case, and even it isn't really > implemented that way. All I'm trying to convey here is arrows can't > tell the whole story, so we can't put an exact definition on what an > arrow really means. Consequently, I can't give you detailed and precise > feedback on how to make the arrows and boxes should look. > > So, use your judgement as to which looks prettier :-) It's an abstraction, it'll never mirror reality perfectly. I'm going to be doing some reading, if that resolves it I wont have to bother you about this again 3.) > We need access to X Server internal data structures that the kernel > doesn't have. So the X Server cant handle its resources independantly, it must co-operate / co-ordinate with DRI? ie X Server talks to kernel on its own, what does it do when there is no DRI? > I believe the resource management example we looked at was window offset > and cliplist. Window cliplists are controlled and updated by the X > Server. Every time a window is moved, the X Server recomputes clip > lists for all affected windows. The 3DDRP has to get this information > from the X Server somehow. OK this could be a gross oversimplification but if I understand correctly there are two RM paths, one for 3D (3DDRP DRM Lib) and one one for 2D (X Server DRM Lib). Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: website. (Jens Owen)
> > I want to get started putting up the new site, but no-one has told me > > how to access the webspace... > > > > I've given my sourceforge details and been added to the project... > > Ian, > > I can't help you with access details, but I'd like you to stage this > below the current main site until we've all had a chance to look at the > new format and get familiar with it. > > I use the current site quite a bit, and this would ease any transition > for me. >From what little I've seen of the new site I wouldnt worry too much about that. If you can use the old one you can use the new one. It'll just look better, have some updated content, etc. Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: agpgart, nFORCE (Al Tobey)
> It's just a guess on the agp gart; the IDE and sound both are clones of > the AMD chip, so why not the gart?. The big whiz-bang feature of the > nFORCE chipset is the crossbar memory controller that supposedly doubles > the bandwidth of DDR (double double data rate). Why would they bother > creating the rest from scratch? Nevertheless, being a graphics chip > company, nVidia might very well decide to create their own GART. Because Sound & IDE are normally South Bridge stuff, so if they are in an AMD chipset board, they would be in the SB, and the Memory controller, AGP, would be in the NB. Unless nVidia / AMD tells you that it is the same, don't hold your breath. Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: radeon cvs problem (ahg@eng.cam.ac.uk) - binary packages
> Just upgraded to the latest radeon dri-cvs (using the binary packages > on SF) and now the X server won't start. This used to work fine with > the 20 May TCL snapshot. > > The kernel module seems to load OK: > > Jun 19 16:30:36 localhost kernel: [drm] AGP 0.99 on Unknown @ 0xec00 64MB > Jun 19 16:30:36 localhost kernel: [drm] Initialized radeon 1.3.1 20020611 on minor 0 > > but the X server crashes. A full XFree86.0.log is below. For > comparison, the 20 May TCL produces an identical log (up to the moment > it crashes) apart from: > > Is there any significance in the different return value from > drmOpenDevice? I was using XF4.1 told that wasnt good enough and had to upgrade to XF4.2. So I did, although I'm not sure I'm getting it 100% right. Tried XFree86.org's tarballs with install script but that didnt work too well. Currently installing: XFree86-4.20-16mdk.i586.rpm XFree86-server-4.20-16mdk.i586.rpm XFree86-libs-4.20-16mdk.i586.rpm (ie rpms from cooker) over a plain install of MDK8.1 with 3D acceleration. I then get a working XF4.2 but without direct rendering. Install a new binary TCL .bz2 package off SF and I get an identical XFree86.0.log. I must still try an old TCL binary from TG instead of SF and see what happens. So you are not alone, the error has been reproduced. Although in my case I suspect the root of the problems is me. On a side note: radeon_dri.so is 5.2MB in the SF d/l and radeon_dri.so is 1.8MB in the TG d/l. Any explanation? Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Difference betwwen the packaging of the Radeon TCL binaries (TG) and the Linux Intel x86 Packages:
Howzit? Having a bit of an issue with the packages from: http://dri.sourceforge.net/snapshots/radeon-20020615-linux.i386.tar.bz2 On a clean install of Linux Mandrake 8.1 XFree 4.1 Kernel 2.4.8 etc Radeon SDR 32MB / AMD 756/758 Linux Intel x86 Packages: radeon-20020615-linux.i386.tar.bz2 Using the above breaks X with not a whole of info in /var/log/XFree86.0.log using: ./install restore - doesnt help. extras package: to /usr/X11R6/bin/XFree86 -doesnt help Radeon TCL binaries (TG) radeon-20020502-i386-Linux.tar.gz Using the above works perfectly. But now with the branch merged into the trunks (discontinued) there will be no more updates... Any ideas? Want me to grep any logs, etc and send the output in, just specify the log, what to search for etc. Bearing in mind that everything is now fine with TG binaries currently installed, and I don't really want it to break it again. Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: agpgart, nFORCE (Al Tobey)
Hallo Dieter > > > It's just a guess on the agp gart; the IDE and sound both are clones of > > > the AMD chip, so why not the gart?. The big whiz-bang feature of the > > > nFORCE chipset is the crossbar memory controller that supposedly doubles > > > the bandwidth of DDR (double double data rate). Why would they bother > > > creating the rest from scratch? Nevertheless, being a graphics chip > > > company, nVidia might very well decide to create their own GART. > > > > Because Sound & IDE are normally South Bridge stuff, so if they are in an > > AMD chipset board, they would be in the SB, and the Memory controller, AGP, > > would be in the NB. > > > > Unless nVidia / AMD tells you that it is the same, don't hold your breath. > > Alan Cox and someone on LKM had something going. > Watchout for -ac kernel changelogs and nFORCE there. > > Have you thried with "agp_try_unsupported=1"? > > modules.conf: > > [-] > alias char-major-10-175 agpgart > alias char-major-10-240 agpgarti810 > [-] > # agpgart is i386 only right now > pre-install mga /sbin/modprobe "-k" "agpgart" > pre-install r128 /sbin/modprobe "-k" "agpgart" > pre-install radeon /sbin/modprobe "-k" "agpgart" > options agpgart agp_try_unsupported=1 > [-] Dankie Dieter But I dont have an nForce, I have and Irongate (756/ 758). I was replying to Al Tobey. cheers Liam --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: agpgart, nFORCE (Al Tobey)
On Sun, 23 Jun 2002 20:15:35 +0200 Dieter Nützel <[EMAIL PROTECTED]> wrote: > On Thursday 01 January 1970 00:59, Smitty wrote: > > Hallo Dieter > > > > > > > It's just a guess on the agp gart; the IDE and sound both are clones > > > > > of the AMD chip, so why not the gart?. The big whiz-bang feature of > > > > > the nFORCE chipset is the crossbar memory controller that supposedly > > > > > doubles the bandwidth of DDR (double double data rate). Why would > > > > > they bother creating the rest from scratch? Nevertheless, being a > > > > > graphics chip company, nVidia might very well decide to create their > > > > > own GART. > > > > > > > > Because Sound & IDE are normally South Bridge stuff, so if they are in > > > > an AMD chipset board, they would be in the SB, and the Memory > > > > controller, AGP, would be in the NB. > > > > > > > > Unless nVidia / AMD tells you that it is the same, don't hold your > > > > breath. > > > > > > Alan Cox and someone on LKM had something going. > > > Watchout for -ac kernel changelogs and nFORCE there. > > > > > > Have you thried with "agp_try_unsupported=1"? > > > > > > modules.conf: > > > > > > [-] > > > alias char-major-10-175 agpgart > > > alias char-major-10-240 agpgarti810 > > > [-] > > > # agpgart is i386 only right now > > > pre-install mga /sbin/modprobe "-k" "agpgart" > > > pre-install r128 /sbin/modprobe "-k" "agpgart" > > > pre-install radeon /sbin/modprobe "-k" "agpgart" > > > options agpgart agp_try_unsupported=1 > > > [-] > > > > Dankie Dieter > > Danke ;-) > > > But I dont have an nForce, I have and Irongate (756/ 758). > > AMD 750 (751/756) Irongate C3-6 (>=C5 with working bypass) ;-) Ag ja 751 (been a while since I've bothered to actually read the numbers) Bypass does work on my board at least it does under Win98 after enabling it. cheers Liam --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: website. (Jens Owen)
On Sun, 23 Jun 2002 22:52:09 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Smitty wrote: > >>>I want to get started putting up the new site, but no-one has told me > >>>how to access the webspace... > >>> > >>>I've given my sourceforge details and been added to the project... > >>> > >>Ian, > >> > >>I can't help you with access details, but I'd like you to stage this > >>below the current main site until we've all had a chance to look at the > >>new format and get familiar with it. > >> > >>I use the current site quite a bit, and this would ease any transition > >>for me. > >> > > > >>From what little I've seen of the new site I wouldnt worry too much about that. > > > > If you can use the old one you can use the new one. > > Don't be that way. I'm not being any way, I'm not actually doing the new site I am contributing to it though, I have spoken to Ian, who's doing it, I have seen screenchot.png, I have given my inputs, requests, etc. Hence: From what I've seen of the new site I wouldn't worry too much about that. Think facelift not functionality changed. (except via a nicer / better / whatever interface point of view) > Jens wants an orderly transition with the opportunity to check the new website > is everything that is claimed for it. If it's not, we'll have a chance to fix > it before it going live. This is just common sense. That would be somewhat insulting if I was in any doubt about my (or lack there of as the case may be) common sense. My message is now what it was then: Be calm, don't panic / worry / etc. cheers Liam --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon SourceForge d/l binaries (the ones everyones bitching about)
Well after beeing told to upgrade to XF4.2 from XF4.1 I did so: So XF4.2 Indirect rendering install the latest / last binary package from TG XF4.2 with direct rendering (no TCL) compile (not install) the latest binary package (20020623) from SF copy every file to its proper location except radeon_drv.o XF4.2 with direct rendering and TCL hey presto it works! (and is of course way faster than indirect and faster than non-TCL) Now you can use the old (TG) or the new (SF): atimisc_drv.o radeon_dri.so but this must be the old (TG) radeon_drv.o glxgears works says stuff about pagefliping quake3 works This curently works as root on my box. of course after playing mix and match with all these files as root I've also to mess up my user account but its backed up so I'll fix that - I dont think that'll be the case with anyone else. thanks to: Matti Valtonen for his valuable input: read your XFree86.0.log you tool note: he was more polite than that Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Website [update!] -> frames colour
Also, the frames need a bgcolor in the body. This is a pet peeve of mine, since I have my default background set to gray. Well if I can see them then I can grab them and resize them. I can also see this line in the old / original site? Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Website comments
From: Keith Whitwell <[EMAIL PROTECTED]> > - There's no easy link to the sourceforge projects page. yes and add the hosted by SF pic below (with some space) redline2 (finishes off the menu frame nicely) - The 'status' page has disappeared > change Hardware to Status in the menu frame. (makes more sense) > - The 'resources' page has disappeared put a link to the 'resources' page in the menu frame. can you find the extra's package I can never find it on the old page - put it on the new one here? - All of the links in the 'developer' page point back to the 'developer' page. > a lot of not implemented links eg documentation (under construction I know) > - The 'help us' link dangles help us link is broken (should this be here - see below - jens) From: Jens Owen <[EMAIL PROTECTED]> > 2) Your plea for help is spread out over the entire site. > Please make sure all potential new developers are aware > they should read the developer FAQ before starting in with > questions on the devel list. Jens explained this to me in very simple language to me a while back when I asked about promoting DRI at university. (search archive) You could use this to explain it to all the three year olds out there who are interested in the DRI project. From: Alexander Stohr <[EMAIL PROTECTED]> > DRI Logo doesnt represent a link to "home". it should be for convenience Yes all of them please, Can we have this back please : Random logo of the moment. Click here to add yours! I don't normally like fancy stuff like this, but seeings as this is a 3D graphics project, and is not required for the site to run I like it. > The previous design had some headers and footers, i dont > think they are required any more to help if the menu bar > grafics didnt load, but for the sake of e.g. pure textmode > browsers without frames they are still helpful. > > Further i would like some copyright statment, in the footer, > even if the pages are free. Knowing the origin is important > as soon as there is at least one mirror site and for people > who do print or quote the pages its as well of interest. From: Leif Delgass <[EMAIL PROTECTED]> > The header/footer navigation links are also useful if another site links > to a URL other than the homepage, since you don't get the frameset in that > case. > Also, the frames need a bgcolor in the body. This is a pet peeve of mine, > since I have my default background set to gray. Well if I can see them then I can grab them and resize them. I can also see this line in the old / original site? Some comments of mine not related to others comments: In the menu frame: Home will get next to redline.png given half a chance, bump it to the next line? As a matter of personal preference I would change the between the items in the menu bar to to space it out a bit, I would'nt like to read that one a 14" when it gets a couple more items in it. I've attached a slightly modified menu.html which fixes the inline and spaces it out a bit. I think it's an improvement over the old site. Sorry Frank but I couldnt stand the way the old menu frame looked under Opera Liam it depends menu.html Description: Binary data
[Dri-devel] Re: Re: Radeon SourceForge d/l binaries (the ones everyones bitching about)
Hei > some my friends reported that this method still not work for Radeon cards > (Xserver starting but dri not work). Testing in progress... :) Me neither (I have a radeon) however it works as root / su (even in a virtual terminal under X logged in as a normal user where it wont work) which makes me think permissions, this even happens if I just install the TG binary packages. I mentioned this in a previous email, hence: > This curently works as root on my box. But apperently its fixed with the latest binary packages from SF, although when I tested 20020624 last night it killed X, so... Will try 20020625 tonight. Liam it depends --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon scratch register writeback patch -> Which radeon is which?
Sorry that this is late but I am behind in my reading of the list. Original Radeons: Radeon VE (no TCl) Radeon SDR Radeon DDR / LE Rereleased Radeons: Radeon 7000 (no TCl) Radeon 7200 (SDR) Radeon 7500 (DDR) The only differences are more RAM and higher clock speeds (possible because of a manufacturing process shrink) on the 7X00 cards. You also get fancy versions of most of these cards eg VIVO, AIW, etc, this is just added functionality ie stick on a tv tuner, a couple of chips. The reason for the renaming is to simplify matters for end users bigger number = better / faster. Furthermore 7X00 denotes a R100 based card and 8X00 denotes a R200 based card. I don't think this needs to go on the website, and now that I've brought that up, how is it coming along Ian? Liam it depends --- This sf.net email is sponsored by:ThinkGeek We have stuff for geeks like you. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: what is hyper-z?
Howzit? > what is hyper-z? a proprietary texture-compression function of the r200? > well, as you expected, performance is exactly the same after the > checkout as before HyperZ has 3 components: Hierarchical Z Discards hidden pixels instead of sending them to be rendered. Z-Compression Performs lossless compression on the Z co-ordinates. Fast Z-Clear Uses a fast method of clearing the Z buffer. Texture compression is something else, ie S3TC or FXTC The Radeon (R100) supports S3TC. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: The Radeon LE? (Mike Mestnik) aka Radeon naming scheme
> # > # List of PCI ID's > # > # Maintained by Martin Mares <[EMAIL PROTECTED]> and other volunteers from the > # Linux PCI ID's Project at http://pciids.sf.net/. New data are always > # welcome (if they are accurate), we're eagerly expecting new entries, > # so if you have anything to contribute, please visit the home page or > # send a diff -u against the most recent pci.ids to [EMAIL PROTECTED] > # > # Daily snapshot on Tue 2002-07-09 10:00:05 > # > > This isn't the only place to find PCI IDs but it seems to explain all the hardware I >have. > > You can take a look at the list if you want, but there's not mention of a card maid >by ATI with an > LE in it's name. The name really isn't important it's the meaning behind the name. >I've got a > "Radeon 7500 QW" Product ID 0x5157, and I also have A "Radeon QL" Product ID 0x514C, >I didn't look > at the sub device to see if That was accurate. I would like to know what the >Product ID of your > "Radeon LE" card is and I'd like to add it to the data base. If it is 0x514C then >where did you > learn that it's also called an LE, I'm just curious? > > Please in the future make it clear what your talking about to avoid confusion, it >seams to me that > the LE's work while the QW's don't It could be that they have different Product IDs, >or that they > just need to be treated as if they did. > > Thank you for your help in sorting this ought. I refer to my earlier email explaining the Radeon naming scheme. This is from the webpage version which I dont think Ian has had a chance to put up yet: Radeon Naming Scheme Original Radeons: Radeon VE (1 texture pipeline, no TCL) Radeon SDR Radeon DDR / LE Rereleased Radeons: Radeon 7000 (1 texture pipeline, no TCL) Radeon 7200 (SDR) Radeon 7500 (DDR) The only differences between the releases are more RAM and higher clock speeds (possible due to a manufacturing process shrink) on the 7X00 cards. You also get fancy versions of most of these cards eg VIVO, AIW, etc, this is just added functionality ie stick on a tv tuner, a couple of chips. The reason for the renaming is to simplify matters for end users i.e. bigger number = better / faster. Furthermore 7X00 denotes a R100 based card and 8X00 denotes a R200 based card. The key line here is: Radeon DDR / LE In other words they are the same card. Legend has is that ATI handed off sonme R100 chips to various companies to make Radeons with them. Up until this point all Radeons were made by ATI. These Radeons would be known as Radeon LE. They differed in that they had a different clock speed, and the silkscreen logo on them was without ATI, ie it only had Radeon on it not ATI Radeon. But the major diffence is that the BIOS had been modified so that the HyperZ functions (see other email) would not work under DirectX, but would still work under OpenGL. Basic product differentation. But *nix doesnt have Direct X so it doesnt matter. AFAIK you can flash your Radeon LE with the Radeon DDR BIOS and then it obviously wont have this problem. WRT to the 8500LE, as has been pointed out its clocked lower, I think this card is more similar to the ATI 8500 than the Radeon LE is to the Radeon DDR. I assume that I'm going to have to add this at some point to the Radeon naming scheme page. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 8500 binary snapshots now available -> Status page.
Great work Keith. > What I've done so far is to extend the existing radeon interfaces to accept > & validate the new state required for the r200, and a couple of other minor > changes. This is probably the minimal set of changes to get a working r200 > driver. It would seem that driver development for the R200 similar to the R100, considering how quickly this driver came out. Is this correct? > A large part of this difference is presumably due to HyperZ - something > that we can't implement in an open driver. Could you please explain why this is, I'd like to know and I'll add it to the documentation, I assume the same holds true for the R100. Do you think a R200_dri_features page (like the one for the R100) would be in order, would you like one? Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 1. SSE on Athlons (and FreeBSD) (Eric Anholt)
> A while ago I added the stuff to the config/cf/* to enable USE_SSE_ASM > on FreeBSD, but today found that it wasn't enabled on my athlon. I > added the proper sysctl check for it, but it still wasn't enabled. It > turns out the Athlon's extended CPUID function has most of the same > feature bits as the standard CPUID features function, but it doesn't > ever enable the SSE bit. I've made a patch that ORs in the bit from the > standard function, enabling SSE on new Athlons. It's attached. > > However, most of the demos I ran saw no improvement from this. The > exception was texcyl, which had an almost negligible but consistent > improvement. This is with a Radeon 7500, RADEON_NO_TCL=1. Are there > any demos in particular that would stress the code that's enabled with > sse that isn't masked out by 3dnow (transforms of normals?)? The total > difference on texcyl between sse/3dnow and no sse/3dnow was on the order > of 1%, so it was a poor benchmark to use. IIRC the CPU must perform a state change to go from SSE to 3DNow! and vice versa, so if you are testing with 3DNow! and SSE as appossed to comparing SSE vs 3DNow! performance this could explain it. I see someone has commented on the BIOS, I wouldnt have thought that would be a problem but you never know. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Fast Writes
> This worked for me, but my Radeon 7500 QL is ok with Fast Writes. > What dose this do, just curious? IIRC an AGP feature which must be supported by both the chipset and the graphics card, just makes things faster, like side band addressing. > > Thanks to the help of Stefan and others I got my r200 to work, from > > Stefans lspci logs I was able to figure out why I lost my signal, it was > > hardware configuration related. I had to disable Fast Writes for AGP, > > simple solution took a bit of time to find, but anyone else having > > problems make sure to check that :o) Which makes perfect sense for Michal Kozlowski problem, old chipset (no / buggy fast write support) and new graphics card (with fast write support). As he (MK) said: > sending commands to the AGP card directly, not having to go through > memory, improving speed. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Website updates
Howzit? Busy going over the website doing some updating, and have a few requests. 1. have a look at the radeon features list, I think the status of a few of those features has changed. 2. Anything else on the website that you can spot that needs updating. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Fast Writes
> > Which makes perfect sense for Michal Kozlowski problem, old chipset > > (no / buggy fast write support) and new graphics card (with fast > > write support). > > > > > This issue is also present for me, I get the same behaviour (X-server > crashes, and blanks the screen) on my box, even though I've got a > relatively new chipset (it's a Via KT266A) > > Maybe it's a general problem with Via Chipsets. Has anybody successfully > tested these drivers with fast write enabled in the bios? If yes, what > mainboard chipset are you using? Well I'm reasonably sure that they would work under windows perhaps I should have added No fast write support in your chipset driver (agp) cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Have a sneak peak at the new DRI website and give your opinions.
email me and I will email you the updated version, it is currently less than 70K uncompressed (it uses the existing site) this version may be up to double that -I'll try to keep it down in size. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Website update - URL
Howzit? Thanks to all those who have been helping me, this has got done a lot quicker than it otherwise would have, and the DRI site is still standing ;-). Anyhow: http://dri.sourceforge.net/site_update/ All comments, suggestions, requests are welcome. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website.
Mike A. Harris wrote: > There's a typo on the Radeon features webpage: > > http://dri.sourceforge.net/other/radeon_dri_features.html > > At the bottom it has "IcDT Gatos" > > Should be iDCT > > (Discreet Cosine Transform) IIRC I wasn't worried how I spelled it originally as it was RFC stage I put (sp?) nobody commented on that for a while, anyway a new version (17 July 2002) of the features list was made then started working on the dri website the new version is reachable from: dri.sf.net/site_update/ Brian Paul wrote: > Fixed. Yes it is / was. Which reminds me /dri/htdocs/ is a real mess and I can't clean it up because I don't have rights to delete things (I think) because the permisions set are for the dri / sourceforge *login* not the *group* dri. I was going to ask for a way around this once the site update had been completed, accepted and moved to dri.sf.net. That hasn't happened (accepted and moved) so I haven't asked. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website.
> > > > Which reminds me /dri/htdocs/ is a real mess and I can't clean it up because > > I don't have rights to delete things (I think) because the permisions set are > > for the dri / sourceforge *login* not the *group* dri. > > I don't understand. As it is now: > > % ls -l > > drwxrwsr-x2 mdaenzer dri 4096 Aug 5 16:41 IRC-logs > -rw-rw-r--1 fworsley dri 4149 Apr 24 15:31 about.phtml > -rw-r--r--1 spyro1 dri 13619243 Jun 24 08:45 backup_imolton.tar.gz > drwxrwxr-x4 fworsley dri 4096 Aug 14 13:08 doc > -rw-rw-r--1 fworsley dri 5744 Mar 13 2002 doc.phtml > > ... they're all "dri" group. Is that wrong? > > "spyro1" and "fworsley" own a few files which aren't group-writable - I can't > fix that. They'll have to do 'chmod g+w" themselves. That would be what I was on about. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI meeting now! #dri-devel
Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website.
On Sun, 22 Sep 2002 21:24:37 -0700 Frank Worsley <[EMAIL PROTECTED]> wrote: > > That hasn't happened (accepted and moved) so I haven't asked. > > I think there is two problems here ... > > 1. Since this is an open-source project there is no single person to > approve the website. Basically I don't think you will get 'approval' > from the group as a whole until your new site has some major advantage > that everyone is going to get excited about. Apparently right now this > is not the case, either because nobody cares about the changes you are > trying to make -or- because you haven't achieved those proposed changes > in your site update ... Understood. See 2. I care more about how it looks. > 2. The main problem Ian Molton and you seem to have with the current > site is that content is hard to find. That is probably a good point, but > I think the way you have reorganized the content is even worse. No offence intended but no, I just think the orignal site looks "none too nice" so does he AFAIK. > I am looking at the your site update right now and every page is very > long, with a multitude of things on a page - many of which don't really > seem to be related. For example, on the downloads page "IRC Meeting > Logs" and "Binary Snapshots". Also, since the pages are very long it is > hard to see what you can find on a page. Quite frankly (no pun intended) IRC logs are about the only thing out of place, and when I look at that page I wonder if I should remove them, however your idea to split documentation back out of help will draw attention back to them on that page meaning they can be safely removed. > Have you considered adding a horizontal line of content links to the top > of the page? One link to an anchor for each major item on the page. No I have not, but I have just learnt what "content links" means. > I believe adding such a "contents link line" to the current site would > make it much easier to navigate. For example on the current "Help & FAQ" > page there could be a line right below the title, with links to "FAQ - > Report Bugs - Mailing Lists". This makes it immediately obvious to > anyone what they can find on that page, without having to scoll and > potentially miss things. Bug reports will be dissapearing (at your request so bad example ) I must disagree on this point (I need persuasion perhaps a really good example / implementation where it works well) because help & status pages are the longest pages they could benefit from it the most (at all) but I like your other suggestions so much that they are about to become shorter and the colour banding makes it a dead simple after that. > Removing the frames from the current page is also a no-brainer since the > top and bottom links line for all major pages already exists. It is also > easy to update those links if they change since they are inserted by a > PHP header/footer function for each page. Ja but if you really don't like frames / can't use them you are catered for so it is not an issue. > A few other things I can think of to change in the current site are: > > - make the PHP dri_header function output all HTML headers and the > actual page title that is user visible. It doesn't do the latter right > now cause I was being stupid. I'm sort of lost I understand the php header funcion and what it did / does but HTML headers? > > - put the "What is the DRI" text from the "About DRI" page on the home > page. Remove the "About DRI" page and the existing junk on the home > page. There is no "About DRI" page. There is currently "What is the DRI" text on the home page already. Junk on the home page? Please be more specific, there is obviously some confusion here are we looking at the same page? > - combine the Resources and Downloads pages into one "Downloads" page > with sections "Binary Packages", "Kernel Modules", "Config Files", > "Other Libraries and Utilities" Thereby remove the old kernel module > sources from the new page. There is one downloads page already?? Although it does have IRC logs, and a CVS section (waiting on someone here). More confusion, same page? > - add a new "Contribute" or "Developer" page that includes our call for > developers from the "Status" page (remove that from the Status page), a > link to the developer FAQ and our mailing lists, link to IRC meeting > times and logs, links to the developer sections of the "Documentation" > page. > > - remove the "Report Problems" stuff from the Help & FAQ page since we > don't use the SF.net bugtracker anyway. Will do, I read about this on the mailing list, but I'm not going to remove it just because I think nobody wants it. > - add the "content links line" to each of these new pages. No. > - remove the frames (if people really dislike them that much) Some do, some don't. As you said can't make everyone happy. > In the end this leaves us with these pages: > > 1. Home - with the "About DRI" text, a nice intro to the project I think this
[Dri-devel] Re: Typo on DRI website.
Howzit Frank? > > Quite frankly (no pun intended) IRC logs are about the only thing out of > > place, and when I look at that page I wonder if I should remove them, > > however your idea to split documentation back out of help will draw > > attention back to them on that page meaning they can be safely removed. > > Ok, I would remove CVS and IRC Logs from that page. They should > re-appear on the "Contribute" page. IRC is already gone, I'm leaving CVS there (for now at least) because is working on scripts to pull CVs, compile etc > > I must disagree on this point (I need persuasion perhaps a really good > > example / implementation where it works well) because help & status pages > > are the longest pages they could benefit from it the most (at all) but > > I like your other suggestions so much that they are about to become shorter > > and the colour banding makes it a dead simple after that. > > If you don't want to add it then that's ok. But I still feel it is hard > to get an overview of what one can find on a page. Maybe put a more detailed site outline on the home page. (see below) > Another way to give a better overview might be to change the font to > something more crisp and readable. I really like Arial or Helvetica for > reading stuff on the web. You could also try increasing the font size by > one. Yeah I must have a look at that, the CSS is not behaving perfectly now that it is inserted via PHP, but this could just be me, the pages on my machine are obviously not rendered as they will be when they are being served up via the webserver so its difficult to guage the effects of changes. But heck it's one file to change cant be that hard. > It would also be good if the titles for items on a page were a bigger > font size, in addition to being bold/underlined. That would make them > stand out a lot better. As above. > > > A few other things I can think of to change in the current site are: > > I think you misunderstood me, the points below apply to the current > site, not your site update. They are just my ideas for what should > change, but it appears you have already addressed a lot of them. > > I should have payed closer attention to your site update before writing > them up. Understood. > > I'm sort of lost I understand the php header funcion and what it did / > > does but HTML headers? > > What I mean is that it should output the title for a page. On your site > that would be the two horizontal bars with the title in between. So then > the source for a page is basically: > > > > [ HTML content here ] > > > > Then if you want to change the basic appearance of a page (title, > header/footer) you can do it in those two functions. Also saves you from > reusing the same header/footer HTML in every page over and over again. Did this already (guess what I was doing monday night instead of economics) > > There is no "About DRI" page. There is currently "What is the DRI" text > > on the home page already. Junk on the home page? Please be more specific, > > there is obviously some confusion here are we looking at the same page? > > Sorry, I ment the current site, not your site update. However, looking > at yours I think you should remove the stuff below the "Mailing Lists" > section. It shouldn't really be necessary to explain the different > links, I just put that on the original page as a filler. Well actually this is similar in concept to your content navigation bar, or at least it could be extended to do this, comments? > > There is one downloads page already?? Although it does have IRC logs, and > > a CVS section (waiting on someone here). More confusion, same page? > > Yes, your Downloads page is good. I would remove CVS and IRC Logs. Also > I would put the config files as the very last item, because I doubt many > people downloads those. CVS stays for now (see above) IRC is long gone, will move config files. > > > - remove the "Report Problems" stuff from the Help & FAQ page since we > > > don't use the SF.net bugtracker anyway. > > Will do, I read about this on the mailing list, but I'm not going to remove > > it just because I think nobody wants it. > > Thinking about this, a better idea might be to say that bugs should be > reported on the dri-devel mailing list. If we do that and it results in > too much traffic/crappy bug reports it can be removed later. But giving > people some way to report bugs is probably a good idea. Must still add some text about report bugs to dri-devel. > > > In the end this leaves us with these pages: > > > > > > 1. Home - with the "About DRI" text, a nice intro to the project > > I think this is how it is. > > > 2. Status - the status of the hardware we support > > With 5 this is how it will be. > > > > > 3. Downloads - downloads of drivers, kernel modules, and other files > > Pretty much identical already. > > > > > 4. Documentation - all of our documentation for developers and end users > > This I like it was a d
Re: [Dri-devel] Re: Typo on DRI website.
> > > Ok, I would remove CVS and IRC Logs from that page. They should > > > re-appear on the "Contribute" page. > > IRC is already gone, I'm leaving CVS there (for now at least) because > > is working on scripts to pull CVs, compile etc > > Why do you need to leave the CVS information there? > It can be garnered from different sources :) To get a response out of you That's where'd I'd put a list of the scripts to d/l. > I just started doing a code review of the r200 driver, hopefully I'll > get around to writing some more scripts within the next few weeks. Well I think r200 is a wee bit more important than scripts, you are free to disagree and work on your scripts though. > > If not, I'll bug Thomasz and have him write something :} Hello Thomas. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website -> XFree86 NDA's
> Speaking of the new web site, could someone please remove the section > in the FAQ that says that various NDA'd documentation can be obtained > by becoming an XFree86 Project member. I'm sure someone could do that, could you point out where this is, I'm certainly not about to read all the FAQ entries to find this. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website -> XFree86 NDA's
> > Speaking of the new web site, could someone please remove the section > > in the FAQ that says that various NDA'd documentation can be obtained > > by becoming an XFree86 Project member. > > I'm sure someone could do that, could you point out where this is, > I'm certainly not about to read all the FAQ entries to find this. Just found it. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website -> XFree86 NDA's
> > Speaking of the new web site, could someone please remove the section > > in the FAQ that says that various NDA'd documentation can be obtained > > by becoming an XFree86 Project member. > > I'm sure someone could do that, could you point out where this is, > I'm certainly not about to read all the FAQ entries to find this. Just found it. Development Issues 3. How can I obtain hardware documentation? Appears to be locked, don't think I can touch this. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website
> > I would say that Effecting a full scale 'all in one go' transition is > > VERY hard. I would suggest letting Liam make the poage official, and > > continue refining the layout. > > I don't see how a transition in one go is very hard at all. The DRI > website is fairly small, all you have to do is cut-n-paste the existing > content and re-arrange it into new pages as you see fit. In terms of getting a working site not at all, in terms of making everyone happy not so easy. > How do you think I made the current website? > > If you can't handle cutting and pasting, the you shouldn't be designing > websites ... That's not quite how I did it, needless to say the content has been cleanly seperated from layout by hand. > > The original layout of content was so illogical that there is really > > no way to transition gradually and still have things make sense. > > Now you are contradicting yourself. You just said it was hard to make a > transition in one go, now you say it is impossible to make a gradual > transition. Which is it then? neither which is why he gave up I seperated it - content done in one go (cut and paste), layout, styling, editing, tweaking, etc done in phases. In other words both ways. > > Liam is a braver man than I - I gave up after doing a significant > > amount of re-organisation, because I couldnt face the problem of doing > > a phased update. > > I don't think anyone wants a phased update. For a site as small as the > DRI site, a one-go replacement makes sense. That is also what I told you > originally when you asked me about it. Phased as in looks - the content's all there except for the outdated bits that have been removed or the new bits that have been added. > > I think that unless anyone has a MAJOR complaint about the new site, > > it should become the default. > > Well, I for one don't think so. The current site didn't replace the > previous site until I had adressed all the problems people had with it. > I went through several revisions of the site on a different server until > it went live on dri.sf.net. btw what about now? > I don't think the standards should be lowered just because you guys > can't handle making revisions to the site before it goes live. I'm not worried about standards it validates at w3c. > > I must confess that I am not surprised that the developers have STILL > > not given Liam a complete list of supported features - despite being > > aske long ago by him, and several times, more recently by me. > > I must say that I am not surprised either. The developers have better > things to do, such as actually working on the drivers (imagine that), > than to compile lists of supported features. David is working on something that may well make this very painless... > > I can download the linux kernel and Hack HAck Hack - its truely open, > > specs and all. I cannot do this with DRI - there are no specs. all I > > can do is poke blindly. > > As I said above, if you were really serious about becoming a developer > you would be able to obtain documentation from the companies. Obviously > you must be doing something wrong ... Don't be petty. I recall from this list lots of people struggling to get documentation. ATI doesn't want HyperZ / iDCT implemented iirc. There's the whole S3TC issue, obviously 3d card manufacturers are being anal about there doc's. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website
> > I think it is much too early for this kind of criticism. While the > > updated website is far from perfect and finished, I definetely think it > > is a clear improvement with respect to the former version. > > I don't see how it is too early for criticism. Liam has indicated > several times that he would like to use the site update as is. If it is > too early to criticize an apparently finished product, then when should > I criticize it? Not too early, but not quite that simple for all intents and purposes the website is finished and has been finished several times. For some reason this always brings out the comments that are needed. These are implemented (or not) depending on how well they are motivated for / against and then the cycle begins again when I squeak up again - I wonder why this keeps happenning > A few other people had already raised the same issues as me even earlier > in the game. I am simply trying to provide some _constructive_ criticism > as to how the site update can be improved so that it can replace the > current site. (see below) > > it is important to get the message out > > Yes it is important to get the message out and that is what the mailing > lists are for. I am pretty sure that anyone how follows dri-devel is > aware of the site update. Yup I've had a large number of "I like", "typo here" (small things) responses, but the bigger more serious changes / requests are few and far between and they disagree! (frames vs no frames; combining pages vs splitting them). But my thanks to all. > > and I would consider any change > > that makes the website more "alive" (+the information can actually be > > found on it) a change for good. There are few things more discouraging > > that a unmaintained website. > > If Liam would address the problems I mentioned, then maybe > the site would go live soon. *If* Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website.
> > I would also recommend that you work together with Nick Leippe. > > Just a quick note to say that I'm still here and happy to help. > My modified version is up for grabs to pick and choose from still at > http://lfm.sourceforge.net/dritest/ Sorry I managed to miss a whole bunch of posts, reading dri-digest quickly means I sometimes skip whole messages, sometimes the whole digest. Not trying to ignore you, heck I even missed some of my "supporters" giving Frank a hard time. And as I mentioned colour banding is there already, and the layout is now a lot like yours the latter after Frank's emails. > If you already have a sourceforge login, you should have all the > access you need to copy the source files if you want anything from them. Got that, don't think I'll be doing that though I had a look at the source of one of your pages, I spent quite a bit of time cleaning up the html by hand of things such as tables, I don't want to do that again. Besides, as I mentioned earlier, at Pawel's suggestion and with his help the site now makes use of CSS, and I re-implemented that PHP header / footer file thing of Frank's, which is where I stuck the CSS, so now the content is pretty much seperated from the formatting and you can change the font style / size / colours etc from one file. Easy maintanence is becoming a reality. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website
> > btw what about now? > > Much, much better. I have a few more comments though . ;) Refer to my email about a certain cycle. > 1. For the mailing list info, there is a link to the old Geocrawler > archives. I think that should probably be removed because SF.net has their > own archives now and they also include the content from the old Geocrawler > archives. You can already get to the SF.net archives by clicking on the > mailing list name and then choosing archives on the following page. It might > be nice to add an archive link right next to every mailing list, so for > example: > > dri-devel [Archives] > dri-user [Archives] > > > > Or just have the mailing list name and have > Subscribe/Unsubscribe/Preferences/Achives next to it like SF.net does. You > can just copy/paste their HTML code. Done something like this. > 2. I really like the new font, it makes things a lot easier to read! But, > the font in the left menu frame is not the same, that should be fixed. You should "arial, helvetica, sans-serif" ring any bells. My mistake was dri.inc isn't used in the menu, besides it never looked ugly under Opera 6 or Netscape 7 iirc. Fixed. > 3. On the status page you have the outstanding infrastructure status at the > bottom. While that certainly is status information, I don't think it fits in > with the other content of the page and is probably also not the kind of > status information a user would be looking for. I suggest you move that > information onto the contribute page and reorganize that page into the > following topics/headings: This I like it, gives the contribute page a reason to exist. > a) "We are looking for more developers" : keep the first three > paragraphs of the intro text as it is now. > > b) "Where to get started?" : link to the developer FAQ, pointer to > mailing lists, link to IRC logs and time (just point to the FAQ questions) > and link to documentation page. So basically the last 4 sentences from the > current page. Ah but with links for those who cant / wont click on Help & FAQ or Documentation even with three (with frames, two without) links on the page. Done. > c) "Outstanding Projects" : the outstanding infrastructure status info, > that would be useful for developers wondering what items still need to be > done (aside from drivers of course). Done and now you begin to see the other need for dri card features lists. > 4. Links on the links page should have target="_top" or "_new" so that they > don't open in a frame. The same goes for the links to the mailing lists and > the links to other peoples pages on the Status page (Leif's page has the > problem, I dunno about the others). Wonder why no one mentioned this, thanks. Nailed those two pages and contribute page, don't think there are anymore, or if they are it's probably better that way. > 5. And my last major major gripe is the frame at the top with the big logo. > It really does take up a lot of screenspace -- even at 1024x768. I really > don't think it's necessary to have it there to remind people that they are > on the DRI site. If you really really want to display the DRI logo I suggest > two things: > > a) BEST --- just put the little DRI logo at the top of the left menu > frame, like on the current site > b) If you really want to have a big top logo on every page, insert it at > the top of the page so I can scroll it out of view. Well I'm leaving it just to bug you Seriously though I think others are far more tolerant of this. > Just modify the dri_header() code for that. I know how to do things, I just don't know which things to do. Now I have a question. In the left hand menu / frame at the bottom is: Hosted by: SourceForge .net Now it is obviously slicker to not have "Hosted by:" but should it (the text) be removed? cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website -> archives
> > 1. For the mailing list info, there is a link to the old Geocrawler > > archives. I think that should probably be removed because SF.net has th= > eir > > own archives now and they also include the content from the old Geocraw= > ler > > archives. You can already get to the SF.net archives by clicking on the > > mailing list name and then choosing archives on the following page. It > > might be nice to add an archive link right next to every mailing list, = > so > > for example: > > > > dri-devel [Archives] > > dri-user [Archives] Well did this. > What about the main central archive? > http://marc.theaimsgroup.com/?l=3Ddri-devel&r=3D1&w=3D2 > > It is fast and dany. I've added your link but, only the one to dri-devel, I'm reasonably sure they can figure out how to get dri users / announce / patch. This is not good though: ?l=3Ddri-devel&r=3D1&w=3D2 Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Spam on this list, list email addresses are out in the open.
Howzit? Having noticed the spam on this list, when I was working on the Mailing list page ( subscribe / unsubscribe / preferences ) this struck me as odd: "To send mail to the list send to [EMAIL PROTECTED]" Now is this not vulnerable to email harvesting web bots which makes the list more likely to be spammed? Perhaps dri-devel AT lists DOT sou An image of [EMAIL PROTECTED] Something to consider? Something else to consider. Is it not possible to strip out the html sections of emails to the lists? Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website -> archives
Op Saterdag, 28 September 2002 20:27:01 Dieter Nützel het geskryf: > Am Samstag, 28. September 2002 19:57 schrieb Smitty: > > > > What about the main central archive? > > > http://marc.theaimsgroup.com/?l=3Ddri-devel&r=3D1&w=3D2 > > > > > > It is fast and dany. > > > > I've added your link but, only the one to dri-devel, I'm reasonably sure > > they can figure out how to get dri users / announce / patch. > > > > This is not good though: > > ?l=3Ddri-devel&r=3D1&w=3D2 > > True, only cut'n paste from my bookmarks ;-) No it's not you, its the verdomde website. (I had a look at it.) > Can you please sort all your stuff (links) in alphabetical order like Graphics > Card Manufacturers for example? Or do it all weighted? But who decides? Links page is definitely weighted where possible eg Projects & OS otherwise alphbetically eg Manufacturers & Distros (I'll fix distro's now) but it's not much of an issu on a really short section eg disto, you can see all of them in a glance. I decide. With the help of anyone who cares to offer an opinion. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website -> archives
> > otherwise alphbetically eg Manufacturers & Distros (I'll fix distro's now) > > Then you only have to fix status.phtml (Supported Cards) to make it equally to > links.phtml (Graphics Card Manufacturers). Well spotted, I'll make the status.phtml alphabetical. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: http://penguinppc.org/~daenzer/debian/dri-trunk/
> > > Why don't you just use > > > > > > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ > > > > This is new to me, > > I guess it wouldn't be a bad idea to mention them somewhere on > dri.sf.net. Who is them? > DRI CVS snapshot packages, so based on 4.2.0. What is it it? Details are needed if you want it (a link) on the website. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: driver feature table
Hi Brian > Attached is an updated table. Good work, when everyone stops pointing out typos etc please email (cc) me a copy, and I'll put it up sometime (wee bit busy atm). Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri_data_flow and control_flow diagrams + explanations
This has been sitting around for a long time, since I got pulled into the website side of things. I wish to put this up as high level design documentation. Any comments? and yes n2s is note to self. Liam it depends dri_flow.tar.gz Description: Binary data
Re: [Dri-devel] dri_data_flow and control_flow diagrams + explanations & website
> > btw is the DDX Driver what causes the XServer to be single threaded? > > I think there are more fundamental reasons. Better change that back then. > > Also sticking up dri_driver_features table by Brian Paul, it may not > > be complete but it is full of info already. > > Yes, looks good. I'd change the Mach64 column for PPC to something like > 'yes (DMA problems)' and the others (except both Intel chipsets) to > 'untested'. Not my baby, if / when it is updated I'll put up the new version. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: how to build
> Liam, perhaps this could be put on the website? I'm happy to put up anything that is deemed useful. But I'm not going to write it. > Can someone do a brief explanation of how to build a CVS DRI on a system > with NO X-windows installation at all, including CVS commands ? > > (I'd like to know before I install X on my new linux box tomorrow...) bit last minute Liam it depends --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri_data_flow and control_flow diagrams + explanations & website
> > This has been sitting around for a long time, since I got pulled into > > the website side of things. > > I wish to put this up as high level design documentation. > > Any comments? > The two documents look great! Up they go. > They match many of my personal notes about architecture :) OK then. btw is the DDX Driver what causes the XServer to be single threaded? Do we still need the old data flow & control flow diagrams? ie data_flow.jpg, control_flow.jpg & control_flow_poster.jpg or are they now redundent? They are as I recall out of date. Anyone know of any copyright issues? Anything that is wrong just shout as the diagrams are done in a vector based graphics program. Also added Debian packages link. Also sticking up dri_driver_features table by Brian Paul, it may not be complete but it is full of info already. cheers Liam --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: non-NDA documentation.
Howzit? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. > Heres a suggestion. > > Can people holding non-NDA chipset documentation please all send it to > smitty and he can put it up on the site? > > If people are paranoid about being sued, I'll happily host it on > mnementh.co.uk I'll quite happily stick just about anything up on the website if it's of a decent quality / standard. Not just up to me though. > here is some driver documentation for VT8601A, without NDA: > http://www.viavpsd.com/product/Download.jsp?motherboardId=3D21 > (filename: DS8601A182.pdf) > maybe thats a good starting point for new developers who have > a notebook or thinclient with this chip. > they could start writing a dri driver without waiting for docs. > Somewhere I found info that the Blade 3d should be almost as > good/fast as an i810, > > heres a forum for mvp4/ple133 mini-itx-board linux users: > http://linitx.org/forum/ I'll also happily link to just about anything if it's of a decent quality / standard. Again its not just up to me though. Of course it'll need more than just this. Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI site overhaul: What about the "DRI Beginner's Guide" etc. sections?
Howzit Dieter? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. > Any progress? With what excatly the guide in the subject line - I've never touched that. With the website see below. > When will we see the move? Merged already. > I pointed someone at the "new" site and first thing was "404 Not > Found"... Please give a URL, although iirc /site_update is no longer valid, I don't regard this as a problem as the correct URL is now just: http://dri.sf.net Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Ati Radeon 8500 - DRI howto.
Hello Bache Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. > I've made a small howto for ati radeon 8500 with direct render support. > I want opinions and suggestions, changes that can make the doc better. > Please take a look at: http://looner.mine.nu/~bkw/dri_8500.txt I haven't had a look yet, but heard good things from those who had. If you will look after your howto I'd like to link to it from the main site as dcoumentation. Or put it on the same server if you no longer have any interest in it. Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Do we have a 3DNow!/SSE switch so that I can test without SSE?
> Seams to me that SSE support in Mesa-5.0/5.1 brakes several things on > Athlon > systems. On Athlon MMX and 3DNow! are shared. Even SSE is "mixed" in. > But "more" parallel...;-) When did this happen I was under the impression state changes were required to get between the various instruction extension sets. Got any links? Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI & Red Hat Kernel 2.4.18 -> Adding FAQ's
> > > I recently upgraded the kernel on my laptop to latest for Red Hat > > > 7.2, called 2.4.18-18.7.x. I then tried to reinstall DRI from the > > > latest dripkg (dated 12/4/2002). The laptop has a Mach64 Rage > > > Mobility graphics chip. After all these upgrades, I can no longer > > > get hardware acceleration. The error message in the XFree86 log is: > > > > > > [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied > > > > This "Permission denied" problem has been reported a couple of times > > now. It seems to occur if the DRM kernel module is compiled with a > > different compiler version than the kernel. AFAIK no one has bothered > > to find out why so far. You can either compile the kernel yourself or > > find out which compiler RedHat used and use the same one for the > > module. > > > > Liam, could you add this to the "Trouble Shooting" section in the FAQ? > > I'm getting tired of answering the same question over and over again OK, done. but I am going to add the link to the add a faq page (now that I know how it works). Please note: use html formatting or else its just one long wrapped line. don't mess it up because you can't edit / delete it If you mess it up I can fix it so don't stress too much. Link for now: http://dri.sourceforge.net/faq/faq_add.phtml Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Joining development
> Hello! > My name if Rudnev Alexey, I have been developing Linux OpenGL-based = > (and also writing my own graphics engines,independent of Mesa) = > applications for quite a long time .I also have some expirience in = > developing(adapting existing to my configuration) video drivers for = > Linux platform. So I think I could be useful for futher development of = > DRI and Mesa. Please,Send me conditions of joining development or some = > other place, where I could find such information. Rundev A.D. = > ,[EMAIL PROTECTED] Hello Rudnev It certainly sounds as if you could be of some use. First have quick look at http://dri.sf.net there's a contribute page, as well as various documents for developers, etc. Brian Paul does Mesa, various people work on various graphics card, which piece of hardware are you interested in? IIRC the procedure is that you find a bug, or get one assigned to you, and fix it, and once you're hooked you just get sucked in. Liam it depends --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI/DRM/stuff overview?
Hi Samium >There is one hopefully nice idea to help DRI developement. > The first and best thing to make a project successful is a good and > clean codebase. The second is a comprehensible set of docs in order to > attract more developers. > > Not that i have paid enough time to find anything, but i think that a > dia overview diagram of the overall structure/APIs would be extremely > nice. > > e.g. how XFree talks to DRM, what DRMs are supposed to provide, DMA > issues etc etc > > also examples could be very useful indeed... You are correct, clean code is good, and I think DRI has that, good documentation is also important. The documentation is not as good / complete as it could be, however if its not there you'll have to write it, reading the source code is recomended. Liam it depends --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] AGP modes
http://grassomusic.de/english/luefter.htm: > AGPx2 can use lower signal levels if the graphics card asks for it, > 1.5V instead of 3.3V (AGPx4 uses 1.5V high state always) Wonder if this has anything to do with why some cards on some motherboards work at some AGP multipliers but not others. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Slackware -> kernel modules situation
Does the quotation below accurately reflect the situation eith kernel modules or not? If not please spell out the correct situation. > > > The information on the web site is wrong in that place, and cause me > > > a great deal of confusion. The kernel modules are now included as > > > part of the XFree86 source code. Just head to > > > > Are you talking about dri.sf.net? If so a URL and the correction > > Yes I am. On dri.sf.net/downloads.phtml it says "You can download the > kernel modules for the latest XFree86 release right here." This should > probably be changed to "You can download the Linux kernel modules for > XFree86 4.2.x here. Kernel modules for subsequent versions of XFree86 > can be found in the XFree86 source tree in the directory > xc/programs/Xserver/hw/xfree86/os-support/linux/drm. > > I think this is factually correct ;) It seems to be the current state > with XF86 4.2.99, I've no idea whether the newer modules will be merged > into the kernel (2.4.20 contains modules for XF86 4.0 and 4.1, but the > 4.1 modules seem to work fine with 4.2) or will remain in the X source > tree. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Re: SUCCESS! Radeon 8500 DRI under RH 7.3! -> documentation
I think this needs to go to dri-devel. That's where the busy person lurks, and it seems to be a good start. > > Actually there has been some work to create a script which will > > identify the card and advise which driver to download, but holiday > > season plus busy people does not make these things happen very fast. > > I think this can be very simple on linux: > > `lspci -n | grep "Class 0300" | cut -d " " -f 4` > > (I don't trust /proc/pci parsers, because the format can change anytime) > > According to /path_to_kernel_source/drivers/pci/pci.ids, Class prefix 03 > is for display controllers, suffix 00 means VGA controllers, suffix 02 > means 3D controllers. > > So we have the vendor and product IDs separated by a colon. Of course, > we must fill a table with the ID-s (and maybe the device classes, when > 0300 isn't good for all cards). And this is, where everyone can > contribute. cheers Liam --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: 64-bit kernel, 32-bit user. Possible? Painful?
> Subject: [Dri-devel] 64-bit kernel, 32-bit user. Possible? Painful? I recall reading somewhere of a Linux (?SuSE?) box based on AMD's forthcoming 64bit x86 cpu, runing both a 32bit and a 64 bit program at the same time, so I'd say its possible. I've no idea how this was being done ie was the 32bit backward compatibility mode being used for the 32bit program and the 64bit mode for the 64bit program. > So, I was thinking about some CPUs that are about to hit the market and > how they will interact with DRI. The main issue that I came across was > with x86-64. When x86-64 systems roll of the line, they'll > (eventually?) have 64-bit kernel support and (for legacy apps) 32-bit > user-mode support. > > My question is, what are the gottchas of having the DRM run in a 64-bit > kernel and the rest of the driver run in either a 32-bit application or > a 64-bit application? Will it even matter? If it will matter, is there > anything we can start doing now to soften the blow? I've nowhere near the knowledge of the interaction between kernel and userland to comment on that. Liam it depends --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Configuration file format survey
Hallo > We've been discussing general issues regarding the new DRI configuration > system recently on IRC. The most user-visible issue is the configuration > file format (until there is a GUI tool ;-). > In any case we need a more structured (nested) format than win.ini since > we want to be able to set parameters per driver/screen/application or > any combination of those. I take it that you set your options for the driver, andoverride them on a per screen basis, whih acre in turn overridden on a per application basis? If so I like that. > We tentatively decided to use XML for the > configuration file as well as for the drivers' specification of > available parameters. Other alternatives which were discussed AFAIR are > a Lisp-like syntax as in the mesa config file, python dictionaries (see > Ians mail "Configuration idea") or something completely home-made. > Unfortunately there seem to be no IRC logs of relevant meetings :-( > > If anyone has serious objections to XML, please let us know (mail to > dri-devel will suffice ;-). Ja, I like .conf style, plaintext. If you want to implement it in XML then I'd definitely want a plain text file which I can edit by hand, in case graphical editing program gets broken, is unavilable, no GUI is available etc. If you can't do it via GUI and the command line its not a good thing. Liam it depends --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Configuration File Example.
Howzit? How about this for something which can be edited by a GUI program which can change the settings, and which I / you / world+dog can read, understand and edit easily in a text editor? GUI *and* CLI editable without having to squint at it. Anyone see any problems if so feel free to educate me. #No spaces except between the connfiguration option and the choice #The only configuration options are those in brackets #Explain how Global config is overwriten by Device which is overwritten #by Program. Global Begin Anisotrophic_texture_filtering(Y/N) Y Bilinear_filtering(Y/N) Y Trilinear_filtering(Y/N) Y AGP_speed(1/2/4/8) 1 End; Device 0 Begin AGP_speed(1/2/4/8) 2 End; Device 1 Begin AGP_speed(1/2/4/8) 4 End; Program Quake1 Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y End; Program UT Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y Vertical_sync(Y/N) Y End; Liam it depends --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Configuration File Example.
> 1) Requires special parser which is too syntax sensitive > 2) Users editing the file could hose it rather easily compared to >existing formats. Ja I know I was teasing the "We want XML" crowd by going to the extreme in the opposite direction, trying to pull them back to the centre. > For a new config file, I personally think it makes the most sense > to use one of either: > > 1) XF86Config style file, and use libxf86config to parse it, >possibly extending the lib slightly as needed. I'd be perfectly happy with this. > 2) One of the XML-is-my-favourite TLA ideas I'd be less than happy with this, XMHell is not my favourite thing. > Either one has a good arguement on both sides. You're trying to drive in the middle of the road, be careful. > Reinventing a new format though buys nothing. I'm of the faith > that good GUI/TUI config tools should be handling everything for > configuration. End user edited config files == bug reports out > the wazoo. I'd prefer to not ship some specialized config format > at all than to ship one that wasn't well thought out, and also > keeps the principle of least surprise. I couldn't care less whether there is or isn't a GUI / TUI configuration program. What I do care about is that the configuration files must be stored in a file which can be edited, run through a script, etc. All the configuration files on my box which I've ever had to edit / bothered to look, have never been in XML, and I don't see a good enough reason to start now. > KISS principle. Also, a bit of open source philosophy - reuse > what exists already, don't reinvent. Well I'd consider XML to not be simpler than XF86Config-4, besides which it is uneccessary, what happened to the "don't implement it if you don't need it" philosophy? cheers Liam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Mailing list maintanence / maintaner
Hi Rich > > Is there anything that can be done to cut down the spam on dri-devel? > > Several other mailing lists I'm on hold submissions by non-subscribers > > for approval. I'd even be willing to sort the non-subscribed emails, > > so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. > I've just started running bogofilter on all incoming email, myself, > though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. > > Or am I just being obnoxious? > > Less so than the spammers. :) I skipped your email because of the subject line. Liam it depends --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI Mailing list maintanence / maintaner
> > >>>Is there anything that can be done to cut down the spam on > > >dri-devel? >>Several other mailing lists I'm on hold submissions by > > >non-subscribers>>for approval. I'd even be willing to sort the > > >non-subscribed emails,>>so that everyone else could avoid them... > > > > > >That would be great, its really starting to get on my tits now. > > > > > >What you've mentioned has been suggested by Alex in response to one > > >of my emails about this. > > > > > >I've tried contacting the list mainatiner privately but it would > > >appear that the maintainer listed under dri-devel list info is > > >incorrect. > > > > > > > > >>I've just started running bogofilter on all incoming email, myself, > > >>though yeah, it'd be nice if it weren't so necessary. > > > > > >I'm on the dri-digest(s) option so I just live with it. > > > > > > > > >>>Or am I just being obnoxious? > > >> > > >>Less so than the spammers. :) > > > > > >I skipped your email because of the subject line. > > > > I'd be happy to see postings restricted to subscribers too. > > > > Unfortunately, I don't know what the list-admin password is. Maybe > > Daryll or Rik do? > > I could do it, but I don't think it's a good idea to restrict those > who are non-members of the list. Cross postings from the xfree86 lists > are sometimes useful. Well Rich already wanted to proof the emails / kill the spam for the list, Alex recomended splitting the list in two, subscribed vs unsubscribed, allowing anything posted by a subscriber through, and filtering the unsubscribed postings. I mean I've heard of Viagra and Propecia (I think) but what the heck Phentermine and Xenical are is beyond me. I assume filtering of sf mailng lists is not possible because filtering on: viagra, porn, mortage - would catch about half of the spam. Liam it depends --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI Mailing list maintanence / maintaner
> > >> I think spam filtering for dri-devel and dri-users would be a good > > >> solution -- IMO, that would be better than moderation. For > > >dri-patches,> the Reply-To is dri-devel. I'd rather have just commit > > >messages and> nothing else on dri-patches. Any comments/replies to > > >specific patches, or> posts dealing with CVS should go to dri-devel > > >anyway. That's why I> suggested limiting just dri-patches to > > >sourceforge addresses. > > > > > >I have only been glancing at this thread, but basically it comes down > > >to this - If the spam bothers you that much setup spam filtering on > > >your personal machine and be done with it. We waste more time and > > >bandwidth talking about what "should" be done (with the list) then > > >actually doing what really "should" be done (with dri). Just my > > >thoughts ... > > > > As stated in my previous mail, I do use spamassassin, and as such > > I do not have a problem with spam. If you're not interested in > > the discussion on despamming, then simply hit DEL on the messages > > that do not interest you, and you'll lose no time at all. If > > other people wish to discuss it, they can, and will. > > > > Freedom of speech. > > Please - what one minute here! > > I hold the freedom of speech very close to my heart for specific reasons > I won't go into. What I wrote above in no way indicates that I want > such a freedom restricted or otherwise removed. That's very nice, but there are limits to free speech. > What I did write above is an indication of my insight into the problem: > > 1) Moderating a list restricts the flow of information (thus in some way > can be viewed as a restriction of speech ... see above). It can be viewed as that if you are trying to view it in that way. Not if you apply the "reasonable man" test. The moderating refers to the deleting of Spam / UCE. > 2) Limiting the mailing list interaction via mail addresses limits the > flow of information (thus in some way can be viewed as a restriction of > speech ... see above). See above. > 3) Implementing a mailing list wide spam filter can remove potentially > beneficial e-mails (thus in some way can be viewed as a restriction of > speech ... see above Besides I know it will never happen unless > we take the lists off of sourceforge and host them else where ... or so > the little birds tell me). Everything has a cost, so what if one in a thousand emails get vapourised, enough emails disapear into the ether, get lost already that this makes no difference, just resend it. Email is not a system whereby 100% of email has to get through, 99.9% is just fine, especially if it gets rid of a decent amount of spam. > Stating that ... too much energy has already been wasted ... on > "spinning wheels". As aposed to implemting more filters / spamassassin, the reason for whih appear to be related to SF as a whole and not anyone on this list. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again) -> FAQ
> > OK, I don't exactly want to stir up this hornets nest *again*, but a > > couple of things aren't entirely clear to me and I'd appreciate any > > clarifications. > > > > As I understand it, the situation is as follows: > > > > The S3TC algorithm is patented and therefore no-one can distribute an > > implementation of the algorithm without a licence from the patent > > holders. > > > > S3TC decompression must be implemented in the hardware (otherwise > > what's the point), therefore hardware which uses S3TC can be assumed > > to have a valid licence to use the code, otherwise the patent owners > > would be down on the hardware manufacturers like the proverbial ton of > > bricks. > > Patent law is actually more complicated than that. I'm not in a > position to go into it, but it gets complicated when you have multiple > components (i.e., software and hardware) working together to implement > something. > > > As far as I'm aware, the main users of S3TC are modern games with > > their vast arrays of textures -- presumably such games come with the > > textures precompressed, or are able to compress them and cache the > > compressed textures themselves. Presumably again, the authors of the > > games have paid for a licence to use the S3TC algorithm from the > > patent holders. > > > > Now, if an OpenGL application has a pile of textures already > > compressed with the S3TC algorithm, then I don't understand why the > > dri drivers can't simply offer the S3TC interfaces to the hardware, > > pass the compressed textures to the hardware and let the hardware get > > on with its licensed decompression of the textures as required. > > Likewise, if the OpenGL application passes compressed textures to the > > S3TC API then how it gets hold of the compressed textures in the first > > place is it's own responsibility -- the OpenGL API just passes them > > on. > > Look at the ARB_texture_compression and EXT_texture_compression_s3tc > specs again. You can specify uncompressed textures and have the driver > compress the AND you can specify compressed textures and have the driver > decompress them (to read them back into the application). For example, > Quake3 can use the S3's vendor-specific extension (can't remember the > name of it right now), but it does NOT have ANY textures pre-compressed. >It expects the driver to do the work. > > Can we add this to the FAQ, please? Instructions at teh bottom of: http://dri.sourceforge.net/help.phtml Alternatively if you know how it works go straight there: http://dri.sourceforge.net/faq/faq_add.phtml No one appears to be abusing it so I'm happy to let it be open. Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again)
> > Can we add this to the FAQ, please? > > The FAQ is editable by anyone isn't it? No, but anyone can add a FAQ, if they could edit / delete them that would be none too wise, which is why I advise not to mess it up (because then I have to fix it). Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI? -> why no one plays with Glide3.
> The 3Dfx Voodoo 3 and Banshee specs are available, as are docs > for other 3D hardware. Who is working on that right now? 3Dfx > released the source code of Glide3 for example. I dont think a > single line of code has been written for Glide3 for 2 years now. Probably because, 3DFX is dead, a V3 gets smacked around by a TNT2, Glide is not neccessary if you have OpenGL or DirectX, and Glide is low level 3dfx only. A useless API for old and slow not to mention dead technology. Which is probably why Molton is trying to instigate a divorce from Glide for the V3. Or am I being too harsh? Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI? -> why no one plays with Glide3. -> documentation.
bad eg and explanation thereof People aren't stupid they know Intel is trying to play in the graphics arena and is willing to do their own drivers, so they let tehm and do something else. OK but here is my take on it, people will work on what they are interested in, so if someone wants to work on R128 and ATI does give out docs for that chip then they should give it to him. Whats the chance of ATI delegating some of this function to TG, ie just give all their hardware programmers guides etc that they are willing to let people see to TG with the understanding that TG only allow people who should see them to get hold of them. Surely TG can respond quicker than a juggernaut like ATI, and then Jon Smirl would have got his docs already and made some progress. This also makes sense in terms of concentrating development of OSS 3D drivers, allowing for higher productivity through division of labour, knowledge concentration, etc, rather than scattering the docs thinly accross the world to individuals. It doesn't compel those who have no interest in DRI but it sure helps those who do. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI? -> why no one plays with Glide3.
> (oh, and please, I prefer being referred to by my first name.) one Molton many Ian's From: "Daniel Vogel" <[EMAIL PROTECTED]> To: "Smitty" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: RE: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3. Date: Sat, 1 Mar 2003 16:35:15 -0500 > a V3 gets smacked around by a TNT2, FWIW, a Voodoo 3 clearly outperforms a TNT2 with Unreal Tournament 2003 (on Windows, using D3D). It's a PITA to develop for though ;) OK how about GF256? I still have lots of cards to name. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI? -> why no one plays with Glide3. -> documentation.
On Sun, 2 Mar 2003 19:34:27 -0500 (EST) "Mike A. Harris" <[EMAIL PROTECTED]> wrote: > On Sun, 2 Mar 2003, Smitty wrote: > > >OK but here is my take on it, people will work on what they are > >interested in, so if someone wants to work on R128 and ATI does > >give out docs for that chip then they should give it to him. > > > >Whats the chance of ATI delegating some of this function to TG, ie just > >give all their hardware programmers guides etc that they are willing to > >let people see to TG with the understanding that TG only allow people > >who should see them to get hold of them. > > I think ATI is more than capable of determining who the are and > are not willing to provide their hardware specifications to. I > of course am not an ATI employee, and I do not know what their > detailed reasoning is for access to their hardware > specifications, nor do I care really, it's their documentation > and they've got their own right to decide who gets what, and > under what circumstances. > > > >Surely TG can respond quicker than a juggernaut like ATI, and > >then Jon Smirl would have got his docs already and made some > >progress. > > I don't think response time is an issue at all. > > >This also makes sense in terms of concentrating development of > >OSS 3D drivers, allowing for higher productivity through > >division of labour, knowledge concentration, etc, rather than > >scattering the docs thinly accross the world to individuals. > > > >It doesn't compel those who have no interest in DRI but it sure > >helps those who do. > > It's a no brainer that the more widely available hardware docs > are for any hardware, the more likelyhood of them being put to > use by one or more people in the OSS community. That isn't a > debateable topic I don't think. This whole issue however has > nothing to do with "who is the arbiter of access to vendor foo's > documentation". > > Any particular vendor may or may not permit access to > some/all/none of their documentation either freely and > publically, or via NDA to specific individuals under whatever > criterion they wish to decide upon. A bunch of people whining on > a mailing list is not going to change that at all. > > In general, someone who goes ahead and works on the code and > makes improvements WITHOUT a vendor's documentation generally has > a better chance at actually getting it. Those who do nothing but > whine on mailing lists that they can't do work on the code > because they don't have the docs, are more likely to never see > them. > > I don't think that any vendor is planning on providing hardware > documentation widespread or to specific individuals based on a > popular vote of some mailing list. There are certain realities > that people must learn to accept and to deal with, and one of > them is that some video hardware vendors do not want to provide > any access to their hardware specifications at all. Others don't > want their documentation widespread and public for whatever > reasons they may have (none of our business really IMHO), but > they may want to support the open source community nonetheless, > and so they provide access to their documentation under an NDA > agreement that they are comfortable with. It allows them to > protect whatever it is they're wanting to protect, and it allows > open source progress to be made as well. We're lucky to get > specifications from any vendor who is willing to provide them to > us under _ANY_ terms. > > I'd love to see more vendors providing specs, and doing so more > openly, and preferably without NDAs. Ragging on vendors who do > permit access to docs under NDA to people of their choosing, for > not providing them to the world, is more likely to dry up access > to specs for _EVERYONE_, and make binary only drivers the only > way of getting modern hardware to work. > > In other words, I believe that whining about these certain > realities, is equivalent to shooting one's self in the foot. Mike you're quite the downer at the moment, been a rough weekend? I couldn't care two hoots about whether or not ATI sits on the hardware documentation or starts distributing it to univertsities as teching aids. What I'm saying is that if they'd decide "gee this document can be released without problem, along with this pile over here and this lot over here can probably be released for use only for writing OSS drivers" then they should go ahead and do it. It would make life a lot simpler for all concerned. Why should people have to fight to get docu
[Dri-devel] Re: future of DRI? -> why no one plays with Glide3. -> documentation.
> >> I'd love to see more vendors providing specs, and doing so more > >> openly, and preferably without NDAs. Ragging on vendors who do > >> permit access to docs under NDA to people of their choosing, for > >> not providing them to the world, is more likely to dry up access > >> to specs for _EVERYONE_, and make binary only drivers the only > >> way of getting modern hardware to work. > >> > >> In other words, I believe that whining about these certain > >> realities, is equivalent to shooting one's self in the foot. > > > >Mike you're quite the downer at the moment, been a rough weekend? > > Neither really. ;o) I'm just expressing my opinion on how > things are, and what we can realistically expect now, and in the > near future, at least from my perspective. I might not be 100% > correct, but it's how I see things from my current viewpoint > anyway. > >I couldn't care two hoots about whether or not ATI sits on the hardware > >documentation or starts distributing it to univertsities as teching > >aids. > > > >What I'm saying is that if they'd decide "gee this document can > >be released without problem, along with this pile over here and > >this lot over here can probably be released for use only for > >writing OSS drivers" then they should go ahead and do it. > > Absolutely. I think they'd (any vendor, not just ATI) do that if > they really wanted to do that. I think the fact that some > vendors do not do that is indicative that they don't want to do > that however, or they would. ;o) I am also implying that they should push those docs into the OSS community rather than make the OSS pull them from ATI. > >It would make life a lot simpler for all concerned. Why should > >people have to fight to get documentation when ATI is in reality > >quite happy to give out certain docs, but because they have > >ceated an awkward process. > > I don't see it as a fight at all. Aside from the very few > vendors who have publically released documentation (such as 3Dfx > Voodoo 3, some older Intel docs, etc.), ATI is one of the vendors > who provides docs to more people under NDA than any of the other > vendors, with the exception of the cards mentioned above and some > other older things here and there. In other words, if the > alternative to a vendors docs under NDA, is no docs at all from > the vendor, I don't think we should complain. Hey ATI is this nicest vendor by far wrt releasing docs / supporting OSS drivers, which is one of the reasons why you should continue to try and get a bit more out of them, I'm not talking to the extent that would damage the comapany here, the end result is OSS drivers for their cards which is hardly a bad thing. > >At the end of the day an NDA isn't much protection, eventually > >the doc will fall into the hands of someone they don't want it > >to, whether someone has to steal it off someone who has signed a > >NDA, find it in the trash, bribe the night staff. > > Well, if people do not honour the NDAs that vendors give, it is a > no brainer what will happen. If someone leaks documentation and > breaks the NDA and it gets back to the vendor, the vendor is most > likely just going to do one of: Ja. > 1) Not provide documentation to people anymore period As I said, all or nothing. > 2) Make the NDA more restrictive and provide documentation to >less people People who violate NDA's don't really care how strict it is. Sort of like: If gun ownership is illegal then only crimanls will have guns. > 3) Provide watermarked docs under NDA to individuals. If docs >leak, they can then sue the person who leaked them, as it is >obvious due to the watermarking Watermarking can be defeated. You can literally retype the entire document in another language with spelling errors. Well at least that's teh first idea that pops into my head > 4) Force developers to work right in the vendor's headquarters in >a monitored room with access to docs that don't leave the >premises (such as some of the Serverworks IDE work, etc.) Is that indentured labour. > >It pretty much is an all or nothing approach. > > > >If they're prepared to release docs to members of TG, why don't they > >release them to TG directly? > > I really don't understand your point here. You are suggesting > that ATI release docs to TG, and then let TG decide who gets them > and who does not get them. ATI is capable of deciding who they > want having their docs, and if they wanted TG to be the people to > decide that, they would ask TG to do that. The fact that that > has not taken place means that they are capable of deciding this > on their own, and that that is not an option that they consider > doing. Assuming they've thought of it, and that they think TG is willing to do it, then they'd ask them. Heck if I was at TG I would probably have put it to ATI to relase docs to TG under whatever agreement they want, why should the docs not all be on hand, it just strikes me
[Dri-devel] Re: dri_driver_features.phtml & dri_radeon_features.html
On Tue, 11 Mar 2003 18:34:16 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: > Smitty wrote: > > Hi Brian > > > > In light of your well maintained: > > http://dri.sourceforge.net/doc/dri_driver_features.phtml > > > > I think it's about time that: > > http://dri.sourceforge.net/doc/dri_radeon_features.html > > crawled into a hole and died. > > > > Do you want to pull in anything from this page or can I get rid of it > > (permanently)? > > As far as I'm concerned you can remove the later. It goes into more > detail than I think is necessary. Perhaps, its got until the end of the week, then it's gone, if anyone wants it, some of the info in it they'd better grab it before then. > The status page seems redundant too: > http://dri.sourceforge.net/dri_status.phtml > > When one clicks on "Status" on the left (or page header) I think the new > table page should come up. Disagree here, the dri_drivers_page won't fit in there, the status page links to some info / websites, that would have to make its way into driver_features first. But I do think that better billing can be given to driver_features on dri_status. cheers Liam --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: dri driver features page -> radeon_naming
> The DRI website contains a few other inaccuracies about ATI's > Radeon video hardware. Nothing mission critical, but it is > incorrect: > > http://dri.sourceforge.net/doc/radeon_naming.html > > Radeon VE a.k.a Radeon 7000, is not R100, it is RV100. So what does this mean for users of DRI? > Another thing missing is the original "Radeon LE", which was made > by a third party in the Asian region. This card is claimed to > have no TCL unit, however it is a Radeon QD and is identical to > any other Radeon R100 cards (which are also QD), and does in fact > have a TCL unit. I believe the BIOS and/or Windows drivers for > this card simply disable the TCL unit, but since the chip is a > QD, like all other QD boards, it has a TCL unit. It's not missing: * Radeon DDR / LE Hidden right in front of you. > The only > difference I know of between this board, and the real "Radeon > 7200" aka "Radeon 64 DDR", is the type and speed of the memory, > and that the TCL unit is somehow disabled via software. 7200 is SDR. > * Radeon 8700 (FireGL) > > It's really called "FireGL 8700" and "FireGL 8800", and both are > as stated on the page Radeon R200 based chips, but neither was > ever marketed as "Radeon 8700" or "Radeon 8800", so that will > just confuse anyone reading it. It is more correct to list this > card the way that ATI names it, under it's FireGL name. Done. > At the bottom of the page: > > * 7X00 denotes a R100 based card. > > Should be removed, as Radeon 7000, is RV100, not R100. We are in disagreement about the relevance of the V. > Also, ATI just released 3 new cards this week, none of which are > supported in X yet, but which are likely incredibly easy to add > support for once the PCI IDs are known. The Radeon 9200 Pro, > Radeon 9600 Pro, and Radeon 9800 Pro Also non-Pro versions of these cards. > Radeon 9200 Pro == RV280 Only problem is that we're beginning to embrace ATI's marchitecture, eg a RV280 is a RV250 on a card with AGP 8x. What is the point of this card? From what spec's I can gather it's going to be smacked around by the recently renamed R9100, so much for numbering schemes. > Radeon 9600 Pro == R300 RV350 > Radeon 9800 Pro == R300 R350 > Just thought I'd post this to help improve the accuracy and > completeness of that Radeon page. It is certainly becoming accurately and completely confusing. Someone over at ATI is playing silly buggers with a once understandable numbering scheme. I think their product line is becoming too large in an attempt to achieve greater market segmentation. I'm trying to strike a balance between keeping it simple and providing all pertinent information. Liam it depends --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri driver features page -> website in CVS
> > PS: Editing files like this makes me kind of nervous, we should really > > work out a way to handle the website in CVS. > > What's the difficulty in having it in CVS? it's extremely trivial to set > up, you just tell the web server to cvs up from the repository every few > hours or so. The website as a whole is rather large, although it is now a heck of a lot smaller after I did some major house cleaning in the last month. These spring to mind: res/ snapshots/ I'm interested in what you say about putting the website in CVS as it should make it easier for developers, who use CVS all the time. But if I'm uploading / editing files on the webserver how is CVS going to remain synced with my newest changes? I'd rather not use CVS myself just for the website, when I mess up a single character I just ssh onto the webserver and use vi to change it. Also when something is being considered I like to test it / play with and update a page repeatedly while hitting the refresh button. I tweak the page like this because many pages have their headers / footers / style sheets added on the server via PHP, and so look very different when they are actually served up. When it's right I .tar.gz and download it, to sync my local copy up with the active copy. All very useful. I'm not a CVS expert so I don't know if you can keep all this functionality alive. Liam it depends --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
> We don't need to put everything into CVS right away, but the way several > people are editing the same files right now is dangerous. Somewhat, at least it makes life interesting. > > I'd rather not use CVS myself just for the website, when I mess up a > > single character I just ssh onto the webserver and use vi to change > > it. > > > > Also when something is being considered I like to test it / play with > > and update a page repeatedly while hitting the refresh button. > > You can still do that, you just do a cvs commit when you're done. >From the webserver? Because that wouldn't be too onerous (dialup is plently slow with plenty lag). > Ideally though, you'd only make changes in your private checkout, commit > when you're done and then bring the public site up to date with cvs up > (which we might be able to automate somehow). Tie updating the website to the commit? I don't see how that would work, I pretty much have to see it served up by the webserver to know when its right. > Of course. :) You're basically emulating parts of the functionality of > CVS with other tools. Well I'm not really opposed to this, so what exactly would this involve (getting it into CVS and then d/l'ing, updating, committing, etc)? I've thought about it a bit more and think that putting just /doc into CVS may be a good idea, the other files either don't change or are only changed by one person at a time / ever. cheers Liam --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
