Re: [Dri-devel] Mach64 development
Hey, ATI has not been very cooperative with letting the documentation out, but they may be now, it took them a month to get the documentation to me, and by then School had started :-( There is a cvs branch for mach64 almost a year old which I have used with limited succes (some gl demos worked, but were corrupted - q3a unplayable), and a new patch which Manuel Teria and Frank C Earl have been working on, but it's over a month old by now. Daryll Strauss wants to see a little more before he'll add a new mach64 cvs branch, and it seems like the DRI project doesn't know how to handle volunteers. Of course people could mess up a cvs tree, but right now there's nothing to mess up. Daryll, could you explain your views on Mach64 again? Carl Busjahn Alex de Landgraaf wrote: >Hey all, > >I too am interested (but my guess is a lot of people are, this mailing >list is probably getting flooded with requests) in the Mach64 DRI. I >checked the CVS but couldnt find a trace of it. Heard some rumors a few >people where developing it in their spare time, but i don't know if >their code has been submitted into the CVS yet. My question is if there >is any code available, and if people are actively developing it. > >Cheers, >Alex > >Ps. my guess is that this would be quite some work, as there are many >chips based on it, all with different levels of acceleration. But who >said it would be easy? ;) > >On Mon, 2001-10-01 at 11:31, Jens-Peter Konrath wrote: > >>Hi, >>I'm interested in the mach64 driver work and would like to help. >>Utah-GLX and Xfree 3.3.6 never worked on my machine, so I decided to >>upgrade to Xf 4.1.0. >>At the moment, I know just very little about video hardware, but if >>someone could point me in the right direction... >> >>Jens >> >> >>___ >>Dri-devel mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/dri-devel >> > > > >___ >Dri-devel mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 development
On Tue, Oct 02, 2001 at 04:54:26PM -0400, Carl Busjahn wrote: > ATI has not been very cooperative with letting the documentation out, > but they may be now, it took them a month to get the documentation to > me, and by then School had started :-( There is a cvs branch for mach64 > almost a year old which I have used with limited succes (some gl demos > worked, but were corrupted - q3a unplayable), and a new patch which > Manuel Teria and Frank C Earl have been working on, but it's over a > month old by now. Daryll Strauss wants to see a little more before > he'll add a new mach64 cvs branch, and it seems like the DRI project > doesn't know how to handle volunteers. Of course people could mess up a > cvs tree, but right now there's nothing to mess up. > > Daryll, could you explain your views on Mach64 again? The general idea is that we need a few developers to "take ownership" of the branch. We generally ask that those developers submit a couple of patches (just so we can look them over) and then we can give them access. We need people interested in keeping up the work, merging branches, dealing with questions, adding new code, etc. It takes some long term dedication and work. >From what I've seen so far the authors weren't particularly happy with how the patches worked, and they weren't up for taking ownership of that part of the project. If I've misunderstood, then the authors should contact me directly. I'm happy to see this ramp up, but so far it hasn't picked up much development momentum. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
On Thu, 27 Sep 2001, Gareth Hughes wrote: > David Johnson wrote: > > > > > They did release specs (under NDA) to many people (including yourself > > through PI/VA Linux). > > > Sure, but not to people in the general open source community, and with the demise of >PI/VA, I would say the chances of a driver done by anyone other than ATI are slim to >nil. Isn't that what we're talking about? Well, we (GATOS) do have the docs, under similar NDA. I believe PI/VA was more "doc-rich" ;) But (looking in them) they document at least basic 3d functionality (don't know about TL and stuff, have not looked thoroughly enough). Keep in mind that what we get is much better than nothing but not as good as we would like. Probably, when ATI writes drivers internally they rely on talking to their hardware people too much. Vladimir Dergachev PS As for Radeon 8500, the major difference seems to be Firewire ports and new PCI numbers. At least, I was assured that in TV-in regard nothing changed much. PSS Doc-rich refers to them allegedly having documentation for iDCT. Now, for conspiracy people, consider this: Loki had iDCT docs and they are in trouble, PI/VA got them - and VA is downsizing.. ;) Just kidding.. > > > -- Gareth > > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
** well, let's see how many flames I can generate with this.. ** On Sun, 30 Sep 2001, Mike A. Harris wrote: > On Fri, 28 Sep 2001, Carl Busjahn wrote: > > >Date: Fri, 28 Sep 2001 11:30:11 -0400 > >From: Carl Busjahn <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Content-Type: text/plain; charset=us-ascii; format=flowed > >List-Id: > >Subject: Re: Re: Radeon 8500, what's the plan? > > > >I have to disagree. If people are really concered about performance > >they should be using Linux anyway. > > That is not disagreeing. ;o) I agree, people concerned about > performance should be using Linux. > > >What David said is also true. I'm not going to reccomend a > >company that doesn't support Linux. We also know that Online > >games require good bandwidth, and the Linux tcp/ip stack just > >tears up anything you can get from Microsoft. Linux could > >EASILY become the de facto gaming operating system. > > Yes, it could become that. In order for that to happen though, > certain things need to occur, including: > > 1) Companies such as Loki, and others need to have a large >enough market to sell to in order to remain profitable. > 2) People have to actually *buy* those games. > 3) Drivers have to exist to push the hardware > > For it to truely be successful, drivers need to be released for > the hardware at the same time as they are released for other > platforms such as Windows. For that to happen, the hardware > vendor has to believe they will see a return on their investments > to write those drivers or pay someone to do so. If they do > envision the market as being there, or at least recovering their > development costs, then they wont likely write drivers. Simple > economics IMHO. Any totally open source driven project to write > such from the ground up, even with specs, is going to trail > behind Windows-land in a game of catch up. > > There has to be a 'big enough' market to drive things to happen. > I fully believe that Linux has the potential to become a > screaming game platform, but that is something that is in the > future - maybe 6 months, maybe a year, maybe 3 years. Who knows. > > Right now, there isn't a lineup of people outside Walmart running > to buy Linux games though, and so it makes sense that hardware > vendors are going to allocate less resources to making these > things happen. > > Again, the potential is there, yes. The actual reality is that > the people who are interested in Linux games succeeding right now > seem to be a small group (yourself, and myself, and probably a > number of people in the list here for example). Me and you, and > the others who want to see games succeed, do not quite seem to > stimulate enough interest, or revenue to make it worthwhile for > someone to fund development. I have faith that this will indeed > change. When is hard to say. > > What can we do to change this? > > 1) Buy all of Loki's games. If you plan on buying a new game, >and a Linux version is available - get it instead of the >Windows version. Same for other companies making games for >Linux. One point that I think has been missed is that while Open Source in general (and Linux, in particular) improves a lot user and developer experience, the binaries get even less value than in Windows. The reason is that when I get binary-only game in Windows, I can at least play it (and reasonably hope that it will still play in future releases). With linux, it will say something along the lines of "works with Redhat 6.2". (take a look at many CAD packages, for example - they are _not_ very graphics intensive). Games are even trickier. I have not bought a single Loki game for this reason: once I upgrade to new libraries or X it will be dead weight. And if it crashes because of incompatibility there is little I can do to fix it. (And no, I am not going to waddle thru machine code to fix something I paid money for). I would say that with Linux, the proper business model should be not "release binary game", but "provide artwork for an existing engine". I.e. have Open Source game engine (bet it Q3 like or Civilization like) and sell artwork for it - artwork which does not crash because of a newer library version. > > 2) Buy hardware from vendors supporting open source, and let them >know what you're using it for. This I agree with - but I would add "supporting with Open Source drivers". Even if you are not buying for Linux consider this: * you might want to install Linux on it in a few years * generally, hardware with Linux drivers is of higher quality - and if not you can easily find snide comments from developers about it. If source code to a driver is available you can take a look at it and have the general idea about how well the hardware will perform. without source the company is free to market it as they wish and blame Windows for poor perfomance. Vladimir De
Re: [Dri-devel] gears problem
I'm using the kernel module from 2.4.10. Everything else is from the Slackware 8.0 release. XFree86 4.1.0 and a Radeon AIW graphics card. - Original Message - From: "Michel Dänzer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 30, 2001 10:24 AM Subject: Re: [Dri-devel] gears problem > On Sat, 2001-09-29 at 18:41, Steven P. Lilly wrote: > > I just installed Slackware 8 with XFree86 4.1.0 and I've come across some > > weirdness with glxgears. When I'm running a window manager everything is > > fine but when I don't run a window manager I get a much higher frame rate > > but what I see is some garbage with a piece of a large red gear. Is this a > > known problem? Has it been fixed if I download a newer version of DRI? If > > you need more info let me know. > > Which driver? Are you using the right kernel module (some drivers need > at least one from Linux kernel 2.4.9 or later or one built from XFree86 > source) ? > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote: > With linux, it will say something along the lines of "works with Redhat > 6.2". (take a look at many CAD packages, for example - they are _not_ very > graphics intensive). Games are even trickier. I have not bought a single > Loki game for this reason: once I upgrade to new libraries or X it will be > dead weight. And if it crashes because of incompatibility there is little > I can do to fix it. (And no, I am not going to waddle thru machine code to > fix something I paid money for). That's just not true. I still run the quake2 binary release which I first used on Redhat 5.something on Redhat 7.1. Quake3 runs better on my Redhat Frankenstein Roswell/Rawhide workstation than it did on Redhat 6.2. -d -- | Damien Miller <[EMAIL PROTECTED]> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
>From: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [Dri-devel] Radeon 8500, what's the plan? >Date: Tue, 2 Oct 2001 17:19:53 -0400 (EDT) > > > >Well, we (GATOS) do have the docs, under similar NDA. I believe PI/VA was >more "doc-rich" ;) But (looking in them) they document at least basic 3d >functionality (don't know about TL and stuff, have not looked thoroughly >enough). Keep in mind that what we get is much better than nothing but not >as good as we would like. Probably, when ATI writes drivers internally >they rely on talking to their hardware people too much. I think you probably got the same docs that PI/VA got and those docs are fairly complete. The advantage of ATI engineers is that they can talk directly to the people who designed the chip. >PSS Doc-rich refers to them allegedly having documentation for iDCT. Now, >for conspiracy people, consider this: Loki had iDCT docs and they are in >trouble, PI/VA got them - and VA is downsizing.. ;) Just kidding.. Loki didn't get low level (i.e. register level) idct docs. They got an idct library with docs on how to use that library. I don't think PI/VA got them either. There is some seriously proprietary stuff with idct that for legal reasons ATI wouldn't want to expose. David _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
On Wed, 3 Oct 2001, David Johnson wrote: > There is some seriously proprietary stuff with idct that for legal > reasons ATI wouldn't want to expose. That is one of the most ridiculous statements I have heard. Substitute some equivalent terms in there: "There is some seriously proprietary stuff with the Pythagorean Theorem that for legal reasons ATI wouldn't want to expose." "There is some seriously proprietary stuff with the quadratic equation that for legal reasons ATI wouldn't want to expose." -jwb ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
> ** well, let's see how many flames I can generate with this.. ** I'll see if I can generate more. >One point that I think has been missed is that while Open Source in >general (and Linux, in particular) improves a lot user and developer >experience, the binaries get even less value than in Windows. > >The reason is that when I get binary-only game in Windows, I can at least >play it (and reasonably hope that it will still play in future releases). > >With linux, it will say something along the lines of "works with Redhat >6.2". (take a look at many CAD packages, for example - they are _not_ very >graphics intensive). Games are even trickier. I have not bought a single >Loki game for this reason: once I upgrade to new libraries or X it will be >dead weight. And if it crashes because of incompatibility there is little >I can do to fix it. (And no, I am not going to waddle thru machine code to >fix something I paid money for). I tend to agree with this. I think a major problem for Linux is forward and backward compatibility issues and compatibility issues between distributions. To be perfectly honest, I think if Linux is to have a future as a 'desktop' or 'gaming' OS a lot of these issues need to be cleaned up. I have written a Linux USB driver that got broken somewhere between kernel 2.4.0 and kernel 2.4.5. How as a driver developer can I ensure that my driver will work on future, supposedly stable, kernel releases? How can the customers of this product get that assurance? Sure, you can say 'release the source and have open source developers maintain it' but to be honest if you want the best support it has to come from the hardware manufacturers. Hardware manufacturers want to (if economically feasible) to maintain the code themselves, release driver updates on their own schedule (not Linus's or Redhat's) and offer support to their own customers. With the highly competitive 3D industry and the need to protect intellectual property I think the future is in binary drivers (like NVIDIA). I feel you are only going to get quality drivers at hardware release time (i.e. support equal to Windows or Mac) if they come directly from the hardware manufacturer. Linux needs to make it simple for the hardware manufactuers to develop and release drivers and for their customers to easily install/upgrade them preferably in a point and click manner. When that happens Linux will be on its way to becomimg a real desktop/gaming platform. Take a look at NVIDIA's linux driver website. http://www.nvidia.com/view.asp?PAGE=linux Is that confusing to a non-technical user or what? Is the average user going to know the difference between "Redhat 7.1 SMP Kernel" vs "RedHat 7.1, one CPU, uniprocessor kernel" vs "RedHat 7.1, enterprise kernel"? Sorry, but that is rediculous. If you guys really want to see Linux become a gaming platform go out and solve these issues. Develop the driver infrastructure so that the kinds of things above don't happen. Develop the driver infrastructure that makes it easy for the hardware manufacturers to develop drivers and support their users. That is how you will take Linux to the next level and make Linux a viable desktop/gaming platform. David _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
Jeffrey W. Baker wrote: > On Wed, 3 Oct 2001, David Johnson wrote: > >>There is some seriously proprietary stuff with idct that for legal >>reasons ATI wouldn't want to expose. >> > > That is one of the most ridiculous statements I have heard. Substitute > some equivalent terms in there: > > "There is some seriously proprietary stuff with the Pythagorean Theorem > that for legal reasons ATI wouldn't want to expose." > > "There is some seriously proprietary stuff with the quadratic equation > that for legal reasons ATI wouldn't want to expose." Okay then... I think what David's suggesting is that ATI's implementation of an iDCT in hardware is pretty cool, and they're not about to go and tell everyone how they did it. Last time I checked, they were the only vendor to offer such a solution, and thus you may want to consider their position on the matter. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
>From: Gareth Hughes <[EMAIL PROTECTED]> >To: "Jeffrey W. Baker" <[EMAIL PROTECTED]> >CC: David Johnson <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >Subject: Re: [Dri-devel] Radeon 8500, what's the plan? >Date: Tue, 02 Oct 2001 18:02:16 -0700 > >Jeffrey W. Baker wrote: > >>On Wed, 3 Oct 2001, David Johnson wrote: >> >>>There is some seriously proprietary stuff with idct that for legal >>>reasons ATI wouldn't want to expose. >>> >> >>That is one of the most ridiculous statements I have heard. Substitute >>some equivalent terms in there: >> >>"There is some seriously proprietary stuff with the Pythagorean Theorem >>that for legal reasons ATI wouldn't want to expose." >> >>"There is some seriously proprietary stuff with the quadratic equation >>that for legal reasons ATI wouldn't want to expose." > >Okay then... > >I think what David's suggesting is that ATI's implementation of an iDCT >in hardware is pretty cool, and they're not about to go and tell >everyone how they did it. Last time I checked, they were the only >vendor to offer such a solution, and thus you may want to consider their >position on the matter. Actually I think SiS offers an idct solution as well but beyond protecting intellectual property there are potential legal issues with exposing how ATI decodes copy righted, copy protected DVD. It may or may not be an issue but I understand why they don't want to necessarily play those games. There are similar issues with releasing TV Out information. David _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
On Wed, Oct 03, 2001 at 01:17:03AM +, David Johnson wrote: > Actually I think SiS offers an idct solution as well but beyond protecting > intellectual property there are potential legal issues with exposing how ATI > decodes copy righted, copy protected DVD. I don't understand what this fuss about hardware accelerated idct is. In which situation you actually get use of it? When I play DVDs on my Duron 650 I get over 50% free CPU time with a software-only dvd decoder (vlc), the card only does yuv->rgb and scaling. It really only helps on older computers, but why would anyone buy a radeon 8500 and put it in an old computer? > It may or may not be an issue but I understand why they don't want to > necessarily play those games. There are similar issues with releasing TV > Out information. Yes, there are problems about macrovision, i.e. the manufacturer shouldn't give out the docs if they can't ensure control of macrovision. Fortunately there has been some progress lately in the area of undocumented TV-Out features, thanks to me . Hmm isn't this dri-devel? Shouldn't we be talking about stuff like how to do DMA efficiently and what new functions to add instead? Brings me back to what I wrote a couple of weeks ago, there is no function in DRI that is able to transfer data from the card to system memory and such a beast could really come in handy when doing video capturing. > David Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- To boldly go where I surely don't belong. PGP signature
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Wed, Oct 03, 2001 at 12:57:55AM +, David Johnson wrote: |... I think a major problem for Linux is forward and | backward compatibility issues and compatibility issues between | distributions. ... There are (at least) two issues here: Binary compatibility for applications, and binary compatibility for driver interfaces (including kernel-resident, X, and client-side 3D drivers, in the case of DRI). Binary compatibility at the driver level is an extremely difficult problem given the variation in hardware across vendors (and even across multiple generations of cards from the same vendor). The DRI people have been working on it. However, unless the vendors providing closed-source solutions eventually agree to a common open infrastructure, there will never be perfect compatibility across vendors. Binary compatibility at the application level is also hard, but doable. For 3D, a Linux OpenGL compatibility standard already exists, and I believe all OpenGL implementations released within roughly the past year conform to it. Most of the complaints in the current thread seem to be focused on application compatibility, so I wanted to make sure that everyone knows that problem has largely been solved. Allen ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Wed, Oct 03, 2001 at 12:57:55AM +, David Johnson wrote: > Take a look at NVIDIA's linux driver website. > http://www.nvidia.com/view.asp?PAGE=linux Is that confusing to a > non-technical user or what? Is the average user going to know the > difference between "Redhat 7.1 SMP Kernel" vs "RedHat 7.1, one CPU, > uniprocessor kernel" vs "RedHat 7.1, enterprise kernel"? Sorry, but that is > rediculous. Indeed. But this isn't the "fault of linux". It happens because nvidia's and kernel devlopers' ideas on how to do this don't mix. > If you guys really want to see Linux become a gaming platform go out and > solve these issues. I could equally claim "nvidia should solve the issues". I don't think it is necessary for the manufacturers to develop drivers. A lot of open source developers would be more than happy to get cool hardware before it gets officially released, sign a NDA and release a driver when the thing gets marketed. This has been done and it seems to work. And I am surely more happy when I sign a NDA with ATI and fix the problems myself than to complain to nvidia that their drivers crash (although I must confess nvidia is doing pretty well considered their drivers are closed source). > Develop the driver infrastructure so that the kinds of things above don't > happen. Turn everything to open-source so that the kinds of things above don't happen. Matter of perspective. > Develop the driver infrastructure that makes it easy for the hardware > manufacturers to develop drivers and support their users. That is how you > will take Linux to the next level and make Linux a viable desktop/gaming > platform. I would agree to this, but my experience says it is more efficient not to plan into much details in the beginning, rather try to design a flexible scheme so you can add new stuff later when need arises. A lot of open-source development follows this path. I think this flexibility and ability to adapt is one of the main linux' strengths and I don't want to kill it in the name of gaming. Sure I want more linux games, but I want it to be done "the right way" (TM), which means that there would be a possibility for a normal guy like me to have access to souce-code to the drivers, even under NDA. I don't think I need source-code to games, if the manufacturer provides support. If a game crashes and I get fragged, big deal. But if a driver crashes and the box freezes I'll be very angry because all the stuff I run at that time gets killed. Oh no now I've done it again. I should stop this and actually do something creative :-) So I'm gonna sleep now and will do some programming tomorrow. > David Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- There's no place like ~ PGP signature
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
>From: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >To: "David S. Miller" <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan? >Date: Tue, 2 Oct 2001 21:59:11 -0400 (EDT) >But, you are right: ID might be afraid to open the product that pays well. >On the other hand, you mentioned millions - how about other companies >teaming up and financing a project ala XFree ? You know, for millions of >dollars... Unless, of course, ID has patents. No, ID doesn't have patents but they have John Carmack who is a 3D genius. Id (and the unreal guys) makes millions because they have the smartest and best 3D developers that create the best 3D engines. If all it took was money for others to create their own engine, they probably would but unfortunately it isn't that easy. David _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Wed, 3 Oct 2001, Damien Miller wrote: > On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote: > > > With linux, it will say something along the lines of "works with Redhat > > 6.2". (take a look at many CAD packages, for example - they are _not_ very > > graphics intensive). Games are even trickier. I have not bought a single > > Loki game for this reason: once I upgrade to new libraries or X it will be > > dead weight. And if it crashes because of incompatibility there is little > > I can do to fix it. (And no, I am not going to waddle thru machine code to > > fix something I paid money for). > > That's just not true. I still run the quake2 binary release which I first > used on Redhat 5.something on Redhat 7.1. Quake3 runs better on my Redhat > Frankenstein Roswell/Rawhide workstation than it did on Redhat 6.2. > I was mostly concerned about Civ III and Might and Magic. Admittedly, (after taking another look now) the recommendations about using special XFree drivers are not there anymore. Perhaps, I'll reconsider and buy some (at least Might and Magic). The windows requirement that I keep the CD in is pretty lame: CDs add to my backpack weight considerably, and, besides, what's the full install for ? On the other hand, perhaps, I should give a try to writing a game engine myself. Vladimir Dergachev > -d > > -- > | Damien Miller <[EMAIL PROTECTED]> \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
On Wed, 3 Oct 2001, David Johnson wrote: > > > > >From: [EMAIL PROTECTED] > >Reply-To: [EMAIL PROTECTED] > >To: [EMAIL PROTECTED] > >Subject: Re: [Dri-devel] Radeon 8500, what's the plan? > >Date: Tue, 2 Oct 2001 17:19:53 -0400 (EDT) > > > > > > > >Well, we (GATOS) do have the docs, under similar NDA. I believe PI/VA was > >more "doc-rich" ;) But (looking in them) they document at least basic 3d > >functionality (don't know about TL and stuff, have not looked thoroughly > >enough). Keep in mind that what we get is much better than nothing but not > >as good as we would like. Probably, when ATI writes drivers internally > >they rely on talking to their hardware people too much. > > I think you probably got the same docs that PI/VA got and those docs are > fairly complete. The advantage of ATI engineers is that they can talk > directly to the people who designed the chip. > > >PSS Doc-rich refers to them allegedly having documentation for iDCT. Now, > >for conspiracy people, consider this: Loki had iDCT docs and they are in > >trouble, PI/VA got them - and VA is downsizing.. ;) Just kidding.. > > Loki didn't get low level (i.e. register level) idct docs. They got an idct > library with docs on how to use that library. I don't think PI/VA got them > either. There is some seriously proprietary stuff with idct that for legal > reasons ATI wouldn't want to expose. Would you know which legal reasons ? I.e. is that only ATI will get into trouble if the publish the docs, or anyone that figures out how iDCT works is liable ? thanks Vladimir Dergachev > > David > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
On Tue, 2 Oct 2001, Gareth Hughes wrote: > Jeffrey W. Baker wrote: > > > On Wed, 3 Oct 2001, David Johnson wrote: > > > >>There is some seriously proprietary stuff with idct that for legal > >>reasons ATI wouldn't want to expose. > >> > > > > That is one of the most ridiculous statements I have heard. Substitute > > some equivalent terms in there: > > > > "There is some seriously proprietary stuff with the Pythagorean Theorem > > that for legal reasons ATI wouldn't want to expose." > > > > "There is some seriously proprietary stuff with the quadratic equation > > that for legal reasons ATI wouldn't want to expose." > > Okay then... > > I think what David's suggesting is that ATI's implementation of an iDCT > in hardware is pretty cool, and they're not about to go and tell Or it could be that the iDCT core was not developed by ATI, but by someone else, and ATI just licensed it. This could explain why they are so adamant about not releasing the docs. As for TV-out they might be afraid that releasing the specs could be consired equivalent to providing Macrovision circumvention device. Or, perhaps, they are under contract with Macrovision.. Vladimir Dergachev > everyone how they did it. Last time I checked, they were the only > vendor to offer such a solution, and thus you may want to consider their > position on the matter. > > -- Gareth > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
> > Loki didn't get low level (i.e. register level) idct docs. They got an >idct > > library with docs on how to use that library. I don't think PI/VA got >them > > either. There is some seriously proprietary stuff with idct that for >legal > > reasons ATI wouldn't want to expose. > >Would you know which legal reasons ? I.e. is that only ATI will get into >trouble if the publish the docs, or anyone that figures out how iDCT works >is liable ? I don't recall all the reasons, or even if they were legally valid, but it was just a potentially messy situation, especially at that time when MPAA was suing everyone. David _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
> >Or it could be that the iDCT core was not developed by ATI, but by someone >else, and ATI just licensed it. This could explain why they are so >adamant about not releasing the docs. As for TV-out they might be afraid >that releasing the specs could be consired equivalent to providing >Macrovision circumvention device. Or, perhaps, they are under contract >with Macrovision.. That is the exact reason for TV Out. Without being able to ensure that a macrovision protected incoming video stream is also macrovision protected going out it could be viewed as ATI releasing a macrovision circumvention device (or helping others create one). That might put ATI in some hot legal water. There are similar things with DVD decoding that ATI must protect so I understand fully if they want to be overly cautious. Their core business depends on it. David _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
On Wed, 3 Oct 2001, Peter Surda wrote: > On Wed, Oct 03, 2001 at 01:17:03AM +, David Johnson wrote: > > Actually I think SiS offers an idct solution as well but beyond protecting > > intellectual property there are potential legal issues with exposing how ATI > > decodes copy righted, copy protected DVD. > I don't understand what this fuss about hardware accelerated idct is. In which > situation you actually get use of it? When I play DVDs on my Duron 650 I get > over 50% free CPU time with a software-only dvd decoder (vlc), the card only > does yuv->rgb and scaling. It really only helps on older computers, but why > would anyone buy a radeon 8500 and put it in an old computer? Well, it would be useful on a notebook pc's (cpu is much less power efficient). I am not familiar with particular implementations, but from mathematical point of view, one should be able to use it to compress video and for this you'll need all the speedups you can get. Vladimir Dergachev > > > It may or may not be an issue but I understand why they don't want to > > necessarily play those games. There are similar issues with releasing TV > > Out information. > Yes, there are problems about macrovision, i.e. the manufacturer shouldn't > give out the docs if they can't ensure control of macrovision. Fortunately > there has been some progress lately in the area of undocumented TV-Out > features, thanks to me . > > Hmm isn't this dri-devel? Shouldn't we be talking about stuff like how to do > DMA efficiently and what new functions to add instead? Brings me back to what > I wrote a couple of weeks ago, there is no function in DRI that is able to > transfer data from the card to system memory and such a beast could really > come in handy when doing video capturing. > > > David > Bye, > > Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 > > -- > To boldly go where I surely don't belong. > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
Around 3 o'clock on Oct 3, Peter Surda wrote: > I don't understand what this fuss about hardware accelerated idct is. In which > situation you actually get use of it? When I play DVDs on my Duron 650 I get > over 50% free CPU time with a software-only dvd decoder (vlc), the card only > does yuv->rgb and scaling. It really only helps on older computers, but why > would anyone buy a radeon 8500 and put it in an old computer? Hardware accelerated iDCT and motion compensation saves energy on laptops. For my machine it should be the difference between not quite finishing a two hour movie and having battery left for hacking before and afterwards. When you're running on batteries, performance can often be measured in joules instead of seconds... [EMAIL PROTECTED]XFree86 Core Team SuSE, Inc. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote: > On the other hand, perhaps, I should give a try to writing a game engine > myself. I know of at least one open-source (LGPL) engine in development: Crystal Space (http://crystal.linuxgames.com). It's a very ambitious project which aims to be a complete, general-purpose, cross-platform engine. I've looked at the demos and it looks very interesting. The success of a project like this would be a big boon to gaming on Linux and other "alternative" OSes. I'm sure they'd appreciate the help. ;) -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Tue, 2 Oct 2001, Leif Delgass wrote: > On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote: > > > On the other hand, perhaps, I should give a try to writing a game engine > > myself. > > I know of at least one open-source (LGPL) engine in development: Crystal > Space (http://crystal.linuxgames.com). It's a very ambitious project Thanks for the pointer :) I was thinking more in terms of 2.1+1d pure software engine - think cartoons. In the end, Quake has already been done. (by +1 I mean time-monotonic rendering. So that if a figure moves left the corresponding points cannot move to the right, though they may stay in the same place. Would be fun figuring out proper algorithms..) Vladimir Dergachev > which aims to be a complete, general-purpose, cross-platform engine. I've > looked at the demos and it looks very interesting. The success of a > project like this would be a big boon to gaming on Linux and other > "alternative" OSes. I'm sure they'd appreciate the help. ;) > > -- > Leif Delgass > > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
You know that there is a reason why they provide the tar.gz file so that people using different kernels can use the driver. The RPMs are simply there for the people that don't o upgrade the kernel and stick with what Redhat gave them, making it easier for them. I don't think that compiling and installing the driver from the tar.gz is terribly hard. As far as knowing the difference between packages, it is the end-user's responsibility to know what hardware/software he has installed on his system so that he gets the right thing. If all else fails RTFM. -- John Tobin [EMAIL PROTECTED]; AOL IM: ogre7929 http://ogre.rocky-road.net http://ogre.rocky-road.net/cdr.shtml On Tue, 02 Oct 2001 18:05:02 -0700 D> Take a look at NVIDIA's linux driver website. D> http://www.nvidia.com/view.asp?PAGE=linux Is that confusing D> to a D> non-technical user or what? Is the average user going to know D> the D> difference between "Redhat 7.1 SMP Kernel" vs "RedHat 7.1, one D> CPU, D> uniprocessor kernel" vs "RedHat 7.1, enterprise kernel"? D> Sorry, but that is D> rediculous. D> If you guys really want to see Linux become a gaming platform D> go out and D> solve these issues. Develop the driver infrastructure so that D> the kinds of D> things above don't happen. Develop the driver infrastructure D> that makes it D> easy for the hardware manufacturers to develop drivers and D> support their D> users. That is how you will take Linux to the next level and D> make Linux a D> viable desktop/gaming platform. D> David ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Tue, Oct 02, 2001 at 03:40:18PM -0700, David S. Miller wrote: >> Actually I think there is a "golden middle way" and ID actually showed it >> too. Release binary games and when some time passes and they see no money >> in engine licenses and maintaining the patches is too costly, release it >> under GPL (see quake1). > Sure, if people don't mind getting a Linux version until several years > later. This is actually a different topic. Q3 was available about the same time on all platforms BTW. > I thought this conversation was about Loki releasing Linux versions > of current generation games. I thought the conversation was about why and which games and cards to buy? My opinion is to buy ATI cards because they have the best support for open source developers and to buy Loki games because they do a good job and also make neat open-source stuff (e.g. SDL) as by-products. By not supporting Loki you are deminishing the chance anyone will ever sell any Linux games, old or new. I think that it isn't such a big problem for an enthusiastic Linux developer to do a little more support than to write programs and docs :-). BTW you are apparently cc-ing emails to "[EMAIL PROTECTED]" (missing "t"). Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Dudes! May the Open Source be with you. msg01918/pgp0.pgp Description: PGP signature
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
From: Peter Surda <[EMAIL PROTECTED]> Date: Wed, 3 Oct 2001 03:19:04 +0200 > I thought this conversation was about Loki releasing Linux versions > of current generation games. I thought the conversation was about why and which games and cards to buy? The thread I responded to was talking about releasing source to the game engine to deal with "compatibility issues" between Linux versions and distributions. It was pretty much agreed that, given how much licensing money companies make from the engines, it is unreasonable to expect this to happen "at release" time. Actually I fail to realize why I even posted anything, as most of postings here on this topic are full of pretty bogus ideas. Maybe a a few of these "way out there" ideas would have a fighting chance during the big tech bubble of last year, but now with the current cash crunch... it's totally unlikely. Franks a lot, David S. Miller [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
On Tue, 2 Oct 2001, David S. Miller wrote: >From: [EMAIL PROTECTED] >Date: Tue, 2 Oct 2001 17:39:25 -0400 (EDT) > >I would say that with Linux, the proper business model should be not >"release binary game", but "provide artwork for an existing engine". >I.e. have Open Source game engine (bet it Q3 like or Civilization like) >and sell artwork for it - artwork which does not crash because of a newer >library version. > > Yep, as soon as companies like ID stop enjoying licensing fees on the > order of a million US dollars a shot for the rights to use these > engines :-) Hmm, I did not know about this. > > Be a realist, there is a lot of money in game engine licensing. So it Still, they sell engines to companies not people. So a NPL-like license would allow the end user to have the code and let them collect royalties as well. But, you are right: ID might be afraid to open the product that pays well. On the other hand, you mentioned millions - how about other companies teaming up and financing a project ala XFree ? You know, for millions of dollars... Unless, of course, ID has patents. > is very unlikely companies will just stop doing so today to make Linux > game releases easier. > > The onus is more so on distribution makers to get the libraries all > compatible and in sync. > > But to be honest I've never run into the library problems you mention > at least amongst the same vendor. So for example, I've installed > vanilla Loki Quake3 from the CD on everything from a Red Hat 6.2 > 7.1 with no problems. All of the point releases from ID installed > fine as well. I had few problems with (demo) quake as well. But Quake isn't my game. When I looked at Civ III it said something about requiring special Xservers - and I decided to stick with Windows version that I already paid for. Vladimir Dergachev > > Franks a lot, > David S. Miller > [EMAIL PROTECTED] > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
From: [EMAIL PROTECTED] Date: Tue, 2 Oct 2001 17:39:25 -0400 (EDT) I would say that with Linux, the proper business model should be not "release binary game", but "provide artwork for an existing engine". I.e. have Open Source game engine (bet it Q3 like or Civilization like) and sell artwork for it - artwork which does not crash because of a newer library version. Yep, as soon as companies like ID stop enjoying licensing fees on the order of a million US dollars a shot for the rights to use these engines :-) Be a realist, there is a lot of money in game engine licensing. So it is very unlikely companies will just stop doing so today to make Linux game releases easier. The onus is more so on distribution makers to get the libraries all compatible and in sync. But to be honest I've never run into the library problems you mention at least amongst the same vendor. So for example, I've installed vanilla Loki Quake3 from the CD on everything from a Red Hat 6.2 7.1 with no problems. All of the point releases from ID installed fine as well. Franks a lot, David S. Miller [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
