Re: [Dri-devel] Re: New ATI FireGL drivers announced
The dri-devel list isn't ATI support. The announcement about the code was fine. I think we all want to know about other versions out there for comparison sake if nothing else. Once people started asking about powered by ati boards, other platforms, and other troubleshooting, it was no longer relevent to DRI development. That's what this list is for. So please take it off line or find an ATI support email address instead. Thanks. - |Daryll --- 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] Updates to texmem-0-0-1 branch
On Fri, Nov 15, 2002 at 11:20:07AM +, Ian Molton wrote: No rush - I wasnt criticising, just making the statement so people would know I intend to have a crack at Voodoo3 support and not drop any code on the floor. I would hope Ian R's texmem stuff doesn't mean dropping the remaining drivers on the floor. That's not really a good choice. There's no problem with some drivers getting the features of texmem and some not, but dropping drivers is a bad idea. I'm glad you're interested in the tdfx. That's still one of the more popular cards out there and getting it updated and removing glide would be a big win. - |Daryll --- 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
Re: [Dri-devel] Savage and nVidia DRI drivers
On Thu, Oct 31, 2002 at 03:58:29PM +, José Fonseca wrote: The Voodoo 2 specs are available from http://www.medex.hu/~danthe/tdfx/ . I don't know what's the current state of the tdfx driver in respect with Voodoo 2. The tdfx driver is quite different from any other driver because it uses the Glide library and everything is done by PIO on the client side. Several times it was manifested the interest in bringing the tdfx driver up to its pairs level and cut the Glide umbilical cord but nothing was done in that sense. V2 specs are publically available as Jose pointed out. The trick with the V2 is that it really is a 3D only card. It doesn't have any sorts of blits, or even cursor support IIRC. It does use a MMAP'd ring buffer, not PIO. The DRI assumes X is running. You'd have to start with that. You can use triangles to do lines and spans and the rest you treat as a dumb frame buffer. It'll be slow, but it is doable. As Keith mentioned, vertices do need to be snapped to 1/16th of a pixel. There's an integer trick for doing that. So the fp in the kernel isn't an issue. Cutting the Glide umbilical cord would be a good project for someone interested. There's been several people who've brought it up, but results have never seen the light of day. - |Daryll --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glXGetProcAddress question
On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote: Ian Romanick wrote: On Tue, Apr 23, 2002 at 12:31:46AM +0100, Keith Whitwell wrote: Ian Romanick wrote: What ends up happening is glXGetProcAddress returns the address of the glBegin symbol from my executable (in this case the address of the pointer to function) instead of the address of the glBegin symbol in the library. Is this behavior to spec? Probably the fact that you are declaring a symbol that is reserved by OpenGL invalidates your right to have GL act according to spec. You might get a link error if you tried to link this program against libGL.so, for instance. So, to put it another way, glXGetProcAddress is working fine, but I'm trying to do something that you're not supposed to do. :) Well, you're doing something you're not supposed to do as a result glXGetProcAddress isn't working right. Do you really need to call your symbol glBegin? How about xyzBegin or similar? The most common thing I've seen is to call the indirect function: glBeginProc - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 12:26:41PM -0800, Ian Romanick wrote: There was some talk awhile back about adding support for AGP texturing in the Radeon driver. Whatever happened with that? I've actually got an implementation of AGP texturing for the Radeon that seems to work. I've also got Michael's 3 TMU patch rolled into my tree. I haven't released any of this yet. Right now the policy for texture management is really simplistic. It tries card memory, then AGP, and finally kicks things off the card. That's really not optimal and I wouldn't recommend it being enabled for general use until something smarter is in place. I suppose I could check this in somewhere since I think it all works. New branch or onto tcl? It's currently based off the trunk. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 09:44:22PM +, Keith Whitwell wrote: Michael also implemented agp support for radeon with a similar simplistic strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think these turned out to be artefacts rather than anything serious. In any case I think he decided to wait on some forthcoming reorganization of the texture management code in all the drivers... (nudge nudge, wink wink) Anyway, it sounds like this has now been done twice: maybe someone should commit something... Since I started with Michael's patch, I don't think we overlapped much. I just fixed a few things along the way. I do agree it should get checked in somewhere. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] assimilate Glide into tdfx_dri ?
On Sun, Feb 24, 2002 at 10:32:43AM +0100, Jacek Pop³awski wrote: Are there any projects to assimilate Glide, i.e. to put Glide source code in tdfx driver? Are there any problems (maybe license?) ? How much performance could be gain this way? As I recall the license really isn't a problem. The issue at hand is that no one is really supporting Glide. It's got a lot of cruft. Rolling it in would then make all that cruft XFree's problem, which isn't reasonable. (For example, that there are different versions of Glide for each type of hardware, which is a pain) Removing Glide by adding only the appropriate functionality to the driver would be a good project for someone who wants to start working close to the hardware. It's pretty well defined and can be done in chunks. You can steal code from Glide as necessary. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 10:54:22PM +, José Fonseca wrote: But on a daily basis!? At least this was the initial plan.. I was thinking in using a script that made some kind of rotation eliminating old releases, only adding a snapshot when there were differences, etc... This can be done on the DRI website, but not on SF release system. Although I knew that Alan's scripts were intended for making full releases I always assumed that the point on making these binary snapshots to have a wider test range. We must decide whether we want target frequent testing or stable releases or both, but *not* at the same time! I propose then again 2 separate releases: - a full stable release on SourceForge (scheduled manualy) - an automated cut-down but with debugging info in client libs on DRI website (or in my server until then) I think this suits everyone purposes. That's a reasonable plan. I didn't mean daily snapshots, but I would like see it updated frequently. We never got to that before and I think that was a mistake. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
On Mon, Feb 18, 2002 at 06:50:36PM -0800, Gareth Hughes wrote: Sergey V. Udaltsov wrote: Hello all Just tried to build mach64 branch. Got an error: make[4]: Entering directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' make[4]: *** No rule to make target `../../../../../../lib/GL/dri/drm/sis_drm.h', needed by `sis_alloc.o'. Stop. make[4]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' make[3]: *** [all] Error 2 make[3]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv' make[2]: *** [all] Error 2 make[2]: Leaving directory `/db2/xfree/xc/xc/lib/GL' make[1]: *** [all] Error 2 make[1]: Leaving directory `/db2/xfree/xc/xc/lib' make: *** [all] Error 2 Any clue? Is it FAQ? No idea... Did you follow the compilation guide? It looks sort of like you didn't do 'make World' and just did make. The main point of this letter: could someone please consider the possibility of periodical publishing mach64.tar.gz using the method of Gatos project: just XFree modules and drm kernel modules (I think, for libGL.* will go there too). The building of the whole tree is time- and space-consuming task, so these builds could simplify the life for ordinary but adventurous people like me. Is it wrong idea? I do not think it is very difficult to hack little shell script which makes this archive... Why limit this to the mach64 driver? We don't build binaries for anything else, and some might argue that other drivers are used more than this one and are thus more worthy of having pre-built binaries :-) If someone wants to take the role of release manager, that would be great. The job is just to keep your CVS tree up to date with all the drivers, build it all (and report any problems), and release make releases to the download page at regular intervals. It isn't a tough job. We even had people make the packaging tools a while back. All it takes is some bandwidth and cycles, which could be run in the middle of the night. So, for those of you looking to help, here's another suggestion. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: GL testing Re: [Xpert]problem with ati and mandrake 8.1
On Sun, Feb 03, 2002 at 08:00:35PM +, Dr Andrew C Aitchison wrote: On Sun, 3 Feb 2002, Vladimir Dergachev wrote: On Sun, 3 Feb 2002, Dr Andrew C Aitchison wrote: I'm fairly sure that there is an OpenGL test suite; although I doubt that it is freely available. Should XFree86 (or another organization) have a licence that can be used to test DRI ? Well, I tried to search for one and asking on DRI list.. I was not able to compile the GL benchmark (viewperf ?) and there was nothing better, so in the end I settled for testing with Quake, Descent and glxgears. There is (or used to be) a test suite which an implementation had to pass in order to use the OpenGL logo. I think that money might have been involved too, although Mesa might have been offered an exemption. Anybody (Brian Paul?) know the details ? You're talking about the OpenGL conformance tests. This is a test suite that tests correctness of some features in OpenGL. You have to sign a license arrangement with SGI to get access to them as it is part of the OpenGL branding process. Brian has a copy for his personal use with Mesa. The tests are not publically available. It may be possible for XFree86 to sign an agreement with SGI to get access to them. VA had worked out a zero cost arrangement with SGI. Realize there are some issues with this. If all you want is more tests to run with OpenGL they would work. You should realize their coverage of OpenGL is actually quite limited, so passing them doesn't tell you a lot. Also, you can only claim a specific set of binaries pass conformance. That means XFree could test their releases, but this would be useless to all the vendors, since they always repackage the release. Building a better test suite that is open would be a real benefit. That's what Glean is all about. I think there'd be more value in building out Glean than working with the OpenGL brand conformance tests. Building good tests can be challenging, but it might be a good project if someone is interested. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote: Regardless of the way it is merged the driver major version will need to be bumped. GATOS drivers does this but only minor - as I did not want to upload a mesa radeon driver just because of the version change. I'm afraid I haven't been following this discussion closely enough, but I found this statement sort of odd, so I thought I'd comment. Version numbers for kernel interfaces are rather different than those for normal software packages. In normal software packages they are more of a vanity thing. A minor version number bump means small things changed, and a major one means hey we did big things. In kernel drivers they are really important as they describe the API between the kernel and the user space application. There are very strict rules about which version numbers are changed when. The major version of a driver should be incremented if and only if there are incompatible changes to the driver that prevent older versions from working. You obviously want to minimize these sorts of changes, so that you don't break compatability. For example, lets say we found a big security hole in an IOCTL. The first thing we'd try to do is rewrite the function so avoid the hole. Maybe even in a way that's really slow. As long as the interface remains the same that's fine. We might add a new interface that's fast again, but keep the old one around for backward compatability. If that's completely impossible then we remove the IOCTL and bump the major version number. If you add or change functionality, but the old drivers still work, then a minor version number should be bumped. Drivers will check for a matching major number and minor number that is greater than or equal to the one they need. So, again if we go back to that security problem. If we rewrote the old IOCTL to be slow but secure and added a new one that is safe and fast, the minor number would be bumped. If you just fix a bug or make some really small change that doesn't impact the interface, then you bump the third digit. Third digits are ignored by the software and are really just documentation. (These paragraphs might be good for a FAQ/Doc somewhere) So, the thing that struck me as odd, is that you said you only bumped the minor version because you didn't want to break Mesa. If your changes do work with Mesa, than bumping the minor version is the right thing to do. We're trying REALLY hard not to change the kernel interfaces. Linus kicked our asses pretty severely about not being careful with kernel version numbers. (Rightfully so) Weve been told in no uncertain terms that if we didn't get this stuff under control it would be removed from the kernel tree. So we should be very careful about how this Gatos functionality is added. It sounds like it should be possible to do it without breaking the API if we put our thinking caps on. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Sure does, but it sounds like we could change the Mesa drivers to have the same behavior as the GATOS drivers. If they see version x.y they use the old offset for AGP and if they see x.y+1 they use the new one. This would be much better than bumping the major version number. I may be glossing over details, in fact I probably am, but putting some effort into this is probably required if we want to be good Linux citizens. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] FreeBSD SiS 630e/300 drm port: who's favorite drm implementation should i mindlessly copy?
The kernel interfaces are highly dependent on the hardware they work with. different in the sense that they all have a common collection of fundamental activities and they all have a collection of disparate activities? or different in the sense that they have *no* common collection of fundamental activities and they all have a collection of disparate activities? Some of the functionality can be generalized and is done in the same way across boards, some can't. Memory mapping the board and dispatching DMA are things that are standardized. You'll find they are templated by using macros. Let's say you're card has some form of primary buffer which contains control functions, and a secondary buffer which contains data for those functions. For example you put the draw triangles command in a primary buffer and the triangle vertices in the secondary buffer. This isn't going to be templated because it is specific to your card. You might be able to fill in both of those buffers safely and securely from user space. Now let's say your card also supports DMA blit as a command. If you allow that command to be accessed from user space you could DMA kernel data (or other process data) into the board (which you could then read back) and that would be a security hole. In that case you might still dispatch the vertex data directly from user space, but you might create interfaces that do a draw triangles or do a DMA blit. The kernel interface would manage the primary buffer, but you'd save the extra work of handling the secondary buffer. If it turns out that the board doesn't handle bad vertices well, say because it hangs the board, then you would need to verify that the triangles are good before sending them to the board and that would require sending them through a kernel interface that would check them. That same sort of checking could be used as another technique for the primary buffer. Instead of submitting the commands through a kernel interface you could build up a big primary buffer and then walk through it looking for dangerous or unexpected commands. So, how much is templated depends on how standardized the cards are. Right now not much beyond DMA dispatch is templated, because we're not convinced anything lower is really common enough to be worth the effort. You can cut and paste to steal from other drivers if you see some overlap. As Keith pointed out the i810 is a pretty sane piece of hardware and therefore has a nice kernel driver. This means the i810 style DRM is one philosphy that works. It isn't the only one, and if your card doesn't act like the i810, then you may need a different philosphy. You really do need to understand how the card functions to design an appropriate kernel interface. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] how does drm handle chipset specific features in a generalized way?
On Thu, Jan 24, 2002 at 12:55:28AM -0600, John Utz wrote: one last question before i knock off for the nite suppose one has two cards. the first, the FooBarTech VisiBlaster, has special hardware for optimizing the generation of very realistic clouds. the second, the BazGrafix RadiantTurkeyBaster XL6000 AGP 4X Value Edition, has special hardware for optimizing the generation of very realistic hair. how would these get hooked up and taken advantage of? how many layers of abstraction get punctured by these nonstandard features? or am i asking the wrong question because they (every graphics chipset) are *all* non standard? can somebody point me to examples in the code? i'd like to be pointed at examples of graphics generation(the hair and clouds stuff) and examples of hardware operation ( ie turning on DVD decoding or enabling the tv-out signal path ). You'd probably implement an OpenGL extension. The NV_* extensions are nVidia specific extensions as examples. How closely this matches your hardware depends on the API you design and the features of the hardware. For it to get accepted as a standard part of OpenGL it would have to be reviewed by the OpenGL architecture review board (ARB). If there were multiple vendors who implemented the feature then the API might need to be changed to standize it. This is one of the current issues with pixle shaders, because the ATI and nVidia API are different, and they've got to get to a common standard accepted by the ARB members. (There's many more issues there, but that's one.) Things like DVD decoding or TV out are even more different. They wouldn't be part of OpenGL at all. They might be X extensions. They might or might not use the DRM as part of their implemention. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] IRC Meeting
Just to make everything clear: Starting at 5pm pacific (that's about one hour from now) On irc.openprojects.net channel #dri-devel We don't have anything formal planned. It'll probably be mostly a QA. Several of the developers should make it for at least some of the time. We can try to schedule a more european friendly time next time. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-devel mailing list archive
On Sat, Jan 19, 2002 at 11:51:33AM +, José Fonseca wrote: I've finished reading (diagonally of course) through the dri-devel mailing lists. It's interesting see 2 years of the DRI development flashing in your eyes in 8 hrs - it's like a novel in that you feel for the characters, i.e., the developers.. :-) More important, after that you start to get used to terms and how things work more or less. But it's not an exercise that is exciting to do: skimming through more than 8000 messages to find less than 5% messages worth seeing. Nevertheless those 5% are a pure gemm. So in this process I've cuttedpasted the more insteresting ones and I'm now compiling them in a DRI Developer FAQ. I think that's a great thing to have done. I'm looking forward to the results. We do need people to step forward and take on projects like this. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM/DRI porting guide?
On Thu, Jan 17, 2002 at 02:40:15AM -0800, [EMAIL PROTECTED] wrote:
Okay, sorry, I just had to laugh. Not your fault, I admit that. You are as innocent
as I used to be.
Here's the deal bro:
Now I'm going to turn this around a bit. You've already seen the answers
from most of us. We're still here, but we're busy with other projects,
and our time is limited. We're all still reading the list and posting
when it seems appropriate.
It's hard work writing docs. It's not a lot of fun (particularly for a
developer) to spend time writing docs.
It is much easier to answer questions than it is to write docs. If
someone takes the initiative to do some digging and ask questions we're
much more likely to respond? Why? Because the scope they're asking for
is more limited. Because they've shown their invested in the
project. You'll find that when you work on open source projects that
lots of people will ask you to give of your time and very few will
contribute on their own.
A good starting point would be to dig through the archives of this list
and collect what's there. It would have a lot of holes, but it would be
a good place to start. I realize it's a pain in the ass, but it's a
start. Has anyone done that? No.
I agree with you that if more modern up-to-date docs were available it
would be easier for other developers to contribute. Pull together what's
on the list already. Ask questions.
Another reasonable complaint is that you need to download too much code
and it takes too long to build all of X. Not everyone has fast machines
and lots of bandwidth. Since the client side OpenGL doesn't change much,
wouldn't it be nice to have a way to compile that separately, so it is
smaller and faster? Yep. Someone do it.
I know I've written this same piece to the list multiple times, but in
order to be more proactive, here's a place to start. All OpenGL drivers
are made up of 3 parts:
A DRI aware 2D driver which lives in
xc/programs/Xserver/hw/xfree86/drivers/...
usually in a file *_dri.{c.h}
A DRI aware 3D driver based on Mesa which lives in
xc/lib/GL/mesa/src/drv/...
A kernel module which lives in
xc/programs/Xserver/hw/xfree86/os-support/drm/linux
Go start digging in those directories and asking questions.
I've given a couple presentations on the DRI, so maybe I can find one of
those to post as well.
Regarding CVS access, Brian, I get email from people, and I talk to
those people that have shown some investment. I've only added one or two
people. My stock answer when asked is that you should submit a patch or
two before we give access. Now one has. For the few people that have
shown some code or even a good understanding, they've turned me down
saying they're too busy.
- |Daryll
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM/DRI porting guide?
On Thu, Jan 17, 2002 at 08:01:14PM +, David Johnson wrote: So, the question is how to we get that process going. As a suggestion, maybe a weekly IRC meeting would help where new developers can ask the experts, and each other, questions about DRI, XFree or 3D graphics. I am sure it would be much easier for Darryl, Paul, or any of the other DRI experts to allocate an hour or so a week to participate in an IRC chat as opposed to monitoring and answering mailing list messages. It would allow the new developers to more quickly get answers to their questions. Also, the IRC logs could be posted on the DRI web site. I like that idea. I could work it into my schedule. As a strawman, how about 5pm (pacific) on Monday? That gives people a couple days to see this and work it into their schedules. I picked early evening, so people could do it after work if necessary and not be late for the east coast folks. It's harder to schedule a global meeting! How's that work for people? It would be great if someone could volunteer to take the log and pull useful bits out for use in documentation. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] agp: what if memory is fragmented?
On Fri, Dec 21, 2001 at 04:05:33PM -0800, Philip Brown wrote: I have a question about what if physical memory is fragmented? The AGIPIOC_ALLOC call returns a 'physical' address. This implies that the ALLOC is a single contiguous chunk of physical memory. Right? However, I cant imagine that it is easy to guarantee 64 megs of contiguous physical RAM allocation. So something seems wrong with my assumption. I've looked at the bsd AGP source, and it uses malloc(), and some fancy bsd magic that I dont understand. Similarly, I do not understand the linux page allocation stuff at all. So, what should be the behaviour of my agp implementation, if contiguous physical memory is not available? I would think it should not be neccessary: thats why the GATT exists, after all?! IIRC, you're in trouble. AGP memory has to be continuous. Jeff always recommended you build the AGP code into the kernel to make sure it happened early enough. In practice loading it dynamically works. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS XFree and StarOffice 6.0
On Sun, Oct 28, 2001 at 02:46:50AM +0300, Papadakos Panagiotis wrote: There are problems with Xfree-4.1.0 and after.I don't know what,but if you want tou use Openoffice-Staroffice 6.0 you will have to work with Xfree-4.0.3. I'm running Open Office 638 on XFree 4.1 just fine. Without more information as to what's happening when you try to run Star Office I don't think we can help you. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] my X-Kernel question
On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote: Would you consider it a good idea to make DRI part of the source of a kernel? Direct 3d graphics supported from the boot sequence. I'm really concerned about your answer. There was a whole thread on the linux-kernel mailing list about the hypothesis of the release of an X-Kernel, a kernel which would include built-in desktop support. Most people answered, no, this would be ridiculous, other said, yes, but hardware manufacturers are too unhelpful therefore this would be totally a totally unstable release. Others said.. other various things. So, what do you think? No, I don't think it is a good idea. Kernel's should provide the minimum layer needed to securly and efficiently implement solutions in user space. The DRI has a kernel component to access the graphics hardware. The rest of OpenGL is in user space. There are lots of advantages to doing it this way: 1) The kernel remains small. No wasted memory. Less security problems. 2) You can layer different graphics systems on top of the same kernel interface. (For example the Xv guys wanting to use it) 3) It easier to change, debug, etc. There's essentially no advantage to having X or OpenGL in the kernel. Do you really need 3D during boot? I'd say no. It can wait until you mount a file system. If you want to get graphics running earlier in the boot sequence, go right ahead and work on that. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Simplified DRM backwards compatibility scheme
On Mon, Oct 15, 2001 at 10:14:33AM -0600, jhartmann wrote: If you have demenstrated that this is the case then we should remove the version system then I guess. I do want to voice my concerns though by writing out my argument fully though. Having a version system is safer. If something does require an incompatible change, like the security fix in the Radeon, then you have some way of invalidating earlier versions. If it turns out that we can keep all the versions compatible that's even better and you just don't indicate that the version change was an incompatible one. Therefore the version system just becomes a safety net and costs us nothing in runtime overhead. In practice, we want to strongly discourage incompatible changes, so it acts like Keith is recommending. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Using drm (fwd)
On Wed, Oct 10, 2001 at 05:13:40PM -0400, [EMAIL PROTECTED] wrote: So, can anyone answer any of the questions below, or do I have to write drm for multimedia ? The DRM is an architecture for accessing hardware directly. What functions are implemented in any given kernel module is driven by the requirements of the applications running on top of it. That's typically OpenGL at that point. So, most of the drivers are not going to have a function call to support your arbitrary DMA. You don't need to write a drm for multimedia you need to add the hooks you require into the exsting kernel modules for various graphics cards. When do you do this, be careful to consider the security implications. Make sure it can't be used to read or write things that it shouldn't. Also make sure it cooperates with the existing driver in the way it uses memory on the card, the state it leaves the card in after its operations, etc. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tdfx, HP_occlusion_test
On Fri, Oct 12, 2001 at 02:15:42AM +0100, Fray Bentos wrote: Hi I submitted a bug report a few days ago concerning the HP_OCCLUSION_TEST extention to opengl on the tdfx driver. Im hopefully gonna fix it myself, but i was wondering if any one can verify that the extension works perfectly on any other (other than the v5500) voodoo card. The bug report ID is 469331, there is a simple glut program to test it. I have attach the prog to this email too. If you cant see the white square or it flickers/blinks the extension is failing (well the glide register read anyhow) Any feedback wil be greatly appreciated. It's almost always useful to test it with the software renderer setenv LIBGL_ALWAYS_INDIRECT That'll force it to use indirect rendering which is software Mesa. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NVidia Driver Source
On Fri, Oct 05, 2001 at 05:36:49PM +0200, Johannes Prix wrote: I read in the FAQ, that NVidia provide their own binary closed source drivers. Yet visiting the Nvidia homepage driver section I find, that there are not only binary drivers for several distributions, but also a source rpm and a source tarball for those interested. Actually I used this source and the explicit and very details compilation and troubleshooting information there to install the driver on my system. It compiled and works well. Have I misunderstood the concept of closed source or is this perhaps valuable and sufficient information for the DRI project? Has there been a change in the attitude of NVidia? Perhaps someone could change those lines in the FAQ, for NVidia has in my opinion done great work. Thanks a lot if anyone has the time to answer this mail. If you look carefully at the source, you'll find it is just a small wrapper for the actual code. All the actual code that operates the card is in binaries. This makes it easier for them to install their driver on different versions of the Linux kernel, but it really is closed source and doesn't provide any useful information to someone who wants to write drivers for the card. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Future plans for project (was: Progress of mesa-3.5 tree?)
On Tue, Sep 18, 2001 at 01:12:34PM +0100, Will Newton wrote: What are the odds of the project coming under the XFree86 umbrella? AFAIK the only reason that DRI was outside of XFRee86 was because it began at PI, and then when it moved to VA Linux they hosted it on Sourceforge (?). XFree86 has a lot of infrastructure in place, would allow better synchronization of releases and has a lot more impact as a brand. e.g. they have a lot of working code and developers, they have a track record. That could be enough to convince card manufacturers that the people they are dealing with mean business. Moving it back under XFree makes a lot of sense. Merging back and forth with XFree is a pain. We've been trying to do that for quite a while. There were a few reasons it has remained separate. First, was that XFree was considered too closed. There have been complaints that our initial design and development was done in a closed manner and we were trying to address that by making them more open. Since then XFree has opened up access to their CVS tree and there is an open discussion group (xpert) that gets used widely. XFree still has the same membership requirements and does have it's own closed lists for various purposes, but you could make a lot more of it be open now. Second, we knew we were going to be going through some very rapid development. We didn't want to wait on XFree's release schedule. We could make new versions available and get them tested prior to XFree releases. This is less true now that the framework is up and there are several stable drivers. Changes a more self contained and don't impact the rest of XFree nearly as much. Third, XFree only gives CVS write access to a small group of people known as the core group. Everyone else has to submit patches and a core member applies them to the tree. We thorught we could deal with this limitation, particularly because several of my team were also core members so we had good control over managing patches if we needed to. Finally, the big thing that stopped us from moving to XFree at this point is that XFree doesn't work on branches. They do all their work on the trunk and only use branches as a means of supporting old revisions. We use branches to keep dangerous changes out of the release until they're ready. Again, the DRI is having less major changes, but we felt this wasn't a good way to handle development. It would have been very difficult to manage the Mesa-3.5 release under this framework. The bottom line is that I'm not arguing against moving to XFree, in fact, I think it is a good idea, but people should realize what issues are involved. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Future plans for project (was: Progress of mesa-3.5 tree?)
On Mon, Sep 17, 2001 at 11:35:33PM -0700, Frank Worsley wrote: 1. Who is going to take on the leadership position for the project? Although this is a community project we do need somebody in charge to act as a sort of project lead and contact person for people outside of the project. Currently Daryll's email address at VA Linux is listed as a contact. Daryll, would you be prepared to maintain such a leadership role? If not, who is going to do it? My name is listed as the webmaster and I am willing to keep doing that. However, I am not in any way qualified to be a contact person for any other issues. A couple of other people come to my mind though .. how about Frank Earl or Manuel Tiera? Both of you have been active on the Rage Pro driver ... or maybe somebody else who wants to step forward? There have been a number of people who have been active lately ... I can't remember everybody so if you are interested send an email to the list. This is not so much a project lead role but more of a contact person role ... see my other points below. Most open source projects tend to work better when they have some small group of active people who own it. They keep track of what's being done, roust developers around release time, etc. Most of the ex-VA guys are still around, although most of us are taking a bit of a vacation/break for a while. 2. We also need somebody promoted to a Sourceforge admin so new members can be added to the project. Right now all of the admins are ex-VA employess. So, if all of them are planning on taking a longer vacation then it would be kind of a problem since nobody can be added to the project anymore. Since we're still here handling the management issues shouldn't be a problem. 3. If we do setup a donation page ... who is going to manage the project's account? How are we going to decide on how the money is distributed? How are we going to decide who gets paid for what? I think Mike made some really good points about donations. I don't think donations for people's time is really going to work. The most effective use of donations would be to buy hardware. There's a lot of logistics to handling that effort, so I'd suggest putting that off until you know exactly how you're going to manage it. 4. I think we have to also start a more coordinated effort to get specs from the hardware developers. This weekend I will sit down and try to come up with a nice document/letter/webpage aimed at management and titled something like Why open source driver development is good for you or something like that. When I get it written up I will post it to the list so everybody can review it. Once we have made something nice I will either email it or mail it to the different companies. Hopefully we can archieve something doing that ... what do you all think? This is where the person in point 1 would come into play, to act as a contact person for the different companies. I don't know if I am being a little optimistic here ... but we have to at least keep trying. I guess the more professional it looks the better. That's probably a reasonable thing to do. As David pointed out I think most companies have heard the arguments, but having a web page doesn't hurt and having standardized letters that request docs and point people to the web page and having centralized contacts would be useful. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Discussion of donation driven DRI project.
On Tue, Sep 18, 2001 at 07:05:59PM -0400, Mike A. Harris wrote: Daryll, are there dri project private lists I presume that could be extended to new developers similar to XFree86's developmental list? There aren't really any at this point. We discussed most things in public, and sometimes on our VA internal list, but it is easy to set such things up for anyone who needs them. I suspect that if a vendor lets you release source code, they'll also let you talk in public, but if it is needed it isn't a problem. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] What source for Rage Pro?
On Tue, Sep 18, 2001 at 10:29:03PM -0600, Felipe Contreras wrote: On Tuesday 18 September 2001 14:41, Andreas Kloeckner wrote: I have the Rage Pro docs from ATI, I would now like to know *how* I can get the source of the driver that people are working on currently for this chip. Also I would like some information on what part of the driver I need to look at. I can hand you what Manuel's already handed out , or you can wait for the merge of my attempts with that (Manuel, I'm still in the middle of that- had something come up on Sunday and I'm about halfway through setting up to make sure I'm not handing out bogus code...). Your pick... I'll be waiting for it too, don't forget to tell us where to start looking at. I'd suggest the latest versions get submitted as patches in the patch database, so that everyone can find them. I know there was a problem with doing that a while back, but I suspect the sf.net team would have fixed it by now. As I've said before, after we get something that sort of works, we can create a branch and let work move to there. It just doesn't seem worth doing that quite yet. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Progress of mesa-3.5 tree? Update to Mesa-3.6/4.0
On Sat, Sep 15, 2001 at 07:08:31AM +0200, Dieter Nützel wrote: That's sad. But how the world goes. Daryll, what are you doing, next? Playing golf, riding motorcycles, and generally taking time off. I'm waiting to see what happens with the relocation, and I'm looking at other opportunities. I've got some time. Some little hope ;-) Good luck to all of you and as always may the source be with you. Thanks. I'm sure it's appreciated. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] VSA-100 chip specs
On Tue, Sep 11, 2001 at 10:04:14PM -0500, Steven Walter wrote: Can someone send a copy of the white papers/references for the 3dfx VSA-100/Napalm my way? Were they even ever released openly? I know that the said document for Avenger (Voodoo3) were, and they used to be availible on 3dfx's website. Unfortunately, though, this website is no longer up, so I can't easily check if the VSA-100 documents were there. Unfortunetly, the VSA-100 specs were never released publically. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] couple of questions about Glide3 ...
On Sat, Jun 30, 2001 at 06:29:13AM -0500, [EMAIL PROTECTED] wrote: 1) is anyone still maintaining the Glide source/CVS ? Not really. 2) anyone noticed problems while compiling Glide3 for Voodoo5 with debug on? I get this error with the GL apps i tried (gears, Quake3, mine), except glxinfo which seems ok: gd.0: GLIDE DEBUG LIBRARY gd.0: cpu: 0x6 _grValidateState: alpha writes enabled even though depth buffering. gd error (glide): _grValidateState: alpha writes enabled even though depth buffering. I suspect that error message is a hold over from preV3 versions of Glide. It is perfectly legal to use Alpha and Depth later hardware, but it wasn't on the V1 or V2. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [volodya@mindspring.com: [Xpert]Guide to debugging DRI installations]
This might be useful to some of the folks here, so I thought I would pass it along. - |Daryll - Forwarded message from [EMAIL PROTECTED] - Date: Wed, 20 Jun 2001 14:41:18 -0400 (EDT) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [Xpert]Guide to debugging DRI installations I've put up a Guide to debugging DRI installations at http://www.linuxvideo.org/gatos/dri-debug.html Comments are very welcome. In particular I seem to have lost the e-mail with comparison of FPS numbers from glxgears with software versus hardware 3d. Can whoever wrote it remind me ? Vladimir Dergachev ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert - End forwarded message - ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] kernel vs. X4.1.0 modules, per Frank Worsley
On Mon, Jun 18, 2001 at 02:48:32PM -0400, [EMAIL PROTECTED] wrote: Good point - I have X4.1.0 and kernel 2.4.5, and no DRI with my Radeon under Linux. 2.4.5 gives me radeon.o in /lib/modules/blah X4.1.0 gives me a radeon_drv.o somewhere in /usr/X11R6/lib insmod /path/to/it/radeon_drv.o doesn't do anything, insmod radeon.o works, but only is version 1.0.0, not 1.1.x How do you force/specify the X module instead of the kernel one? The Linux kernel sources will be updated with the XFree 4.1 modules some time soon. I don't think separating them is a good idea. The problem is that if you're outside the kernel you have a much harder time tracking the kernel changes. We've discussed it. It has pluses and minuses, but I think having it in the kernel is a better choice. Your problem is that radeon_drv.o isn't the kernel module, it's just one of the .o files. You need radeon.o The correct directory is: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel You can do a compile in that directory even if you haven't built all of X. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage128 and VIA KT133
On Mon, Jun 18, 2001 at 01:28:33PM -0700, Frank Worsley wrote: - Frankÿÿÿî/Ýz÷¥¨¥x%ËC®/Ýz÷¥þX¬¶Ïì¢êÜyú+ïçzØm¶ÿþX¬¶Ïì¢êÜyú+ïçzßåËlþX¬¶)ߣ÷k÷^ Is that Unicode for Worsley? :-) - |Daryll ¸z÷¥¨¥x%ËC®'^½éeËl²«qç讧zØm¶ÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~Ý®'^½é
Re: [Dri-devel] SPAM
On Wed, Jun 13, 2001 at 12:34:22PM -0400, Jon Niehof wrote: Did anyone else get spam apparently harvested from this list? Yes, I goofed and approved a piece of spam that put in the moderation queue. Your addresses have not been picked up. I shouldn't go through the queue when I'm still waking up in the morning. Sorry about that. :-) - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI documentation ...was Re: [Dri-devel] Announcement
The documentation makes a good base and is mostly still correct. The problem is that this stuff is growing very quickly. For example, we've come up with fairly standardized ways of writing a device driver. From an architectural point of view it's still just a device driver, but from an implementation point of view it would be nice to have more documentation that describes how everything fits together. As with any engineering project it is tough to create current documentation. Documentation quickly becomes outdated. There's no documentation for the Linux kernel either for pretty much the same reason. Your best bet is going to be to dive into the code, and ask questions if you get stuck. - |Daryll On Fri, Jun 08, 2001 at 02:58:15PM -0500, [EMAIL PROTECTED] wrote: I don't want to beat it to death, but following the Announcement sparked discussion I wanted to mention my take: One of my problems (time being the biggest one of course :) with getting involved with the code-part of the DRI project was the developer documentation. I am greatful for having some of it (I have read these a few times: DRIintro.html dr.html drm.html security.html DRIdataflow.jpg DRIcomponents.jpg Free86-DRI.html drill.html locking.html ), but I still found myself needing more to grasp the inner workings of the DRI better. (some were basically function prototypes/descriptions which didn't tell me much about how and where these functions where used) So since I am speaking of the PI docs, I would like a response from the PI guys in the list: how current are these docs to the present-day DRI ? While reading them I saw many mentions about features that were to be implemented in the future, (seems the docs were done in time for some LinuxShow/Conference demo) and got the feeling that the docs were quite out of touch with present- day DRI. Of course I know the dates of the docs, but how applicable are they today? Just want to get an idea, because if I use them as my base of understanding for the DRI (as I do today), then I want to know how off-base I am. I realize that going through the code would answer this for me, but I am not that familiar with it ; I am still working on grasping the high-level layout of the project. I know how to bang registers and stuff like that makes sense, but the overall flow of things is my struggling point. thanks tony Free, encrypted, secure Web-based email at www.hushmail.com PGP signature
Re: [Dri-devel] Re: Re: Re: Announcement
On Thu, Jun 07, 2001 at 06:21:38PM -0400, Mike A. Harris wrote: Yep. I think any serious project out there works the same way also, at least all the Sourceforge projects do. With XFree86 specifically I don't even know who all has CVS write priveledge. Do just the core developers have write privs, or do other developers do too? I've never needed/wanted to try a write operation to find out personally. I'm happy sending patches in, as that assures that someone much more familiar with the code gets to eyeball my potential change. With other projects, I think that is a good thing to do as well. XFree86 has a dozen or so core developers. They're the only ones with write access to the CVS tree. Everyone else just submits patches and the core members apply them. The advantage of that is that they get reviewed before being applied. Our DRI tree is a bit more open. We ask that people submit their first few changes as patches, which we review and apply. If those go well we give them write privledges. That works a bit easier for us, because we force all the development onto branches. Developers can have a safe play pen to work on things and then they just have to be careful before they merge onto the trunk. (We try to work with them to make sure they test everything before merging) The DRI tree and XFree86 tree are bidirectionally sync'd fairly often. Our trunk should always be fairly close to XFree86's. Our branches might have wild divergence as we do something more major (like Mesa 3.5) - |Daryll PGP signature
Re: [Dri-devel] Right thing to do with 4.1.0?
On Sun, Jun 03, 2001 at 01:56:21PM -0700, Jeffrey W. Baker wrote: I am not clear about the state of the DRI tree with regard to the new XFree86 release. I updated my CVS tree and was surprised to find that only a few minor changes had been made since my last update on May 21. Does that indicate that the DRI tree is already synced with the XFree86 4.1.0 tree? I feel like the best thing would be to install XFree86 and install the DRI tree in parallel, as I usually do. Is that safe at this time? I'm not keen to switch to the mesa 3.5 branch :) We keep the two trees very close. We try to merge each of the XFree86 interum releases. So you shouldn't see much change between our tree and XFree86! What will happen next is that XFree will start work on 4.2 and we will start doing more major changes (like incorporating the Mesa 3.5 tree). - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Glide + XFree86
On Sat, Jun 02, 2001 at 02:29:21AM +, Andrew Richardson wrote: What is exactly involved with this? Is it basically rolling glide functions into the tdfx driver code? If so that's easy, right? And how does things like libtexus (?) fit in to this? Although I can't promise anything I can try to look at this over the summer. That's most of the work, but you'd be better off if you did more than just copying the functions from Glide into XFree86. For example, Mesa keeps track of all the state as does glide. To change a context we tell Glide to restore it's state. It would use less memory and could avoid checking extra state. If you look at tdfx_wrapper.[ch] you can see what functions are used. It would be a good summer project. The trickiest part will be pulling out (and simplifying) the initialization code. Another thought if we can remove the glide3.so dependency of the tdfx driver, it is possible to write a glide-OpenGL wrapper to enable people to use glide using DRI, although Im not sure if this is a runner inasmuch there are few glide games for linux now (though with WINE there could be a load more soon). Lots of people have talked about it. It's much harder than you think to do well. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon on Irongate: DRI locks up machine instantly
On Tue, May 29, 2001 at 02:20:01PM +0100, Stephen C. Tweedie wrote: Hi, On Tue, May 29, 2001 at 02:00:33PM +0100, Philip Willoughby wrote: I'm using VIA Irongate too. Err, AMD make the irongate chipsets -- the 75x series. VIA don't -- they make the Apollo series Which have you got? My bad, it's Irongate 75x. Folks, there are obviously some problems with AGP on the Irongate chipsets. Those drivers were written without full documentation and given the reports it seems clear there's something wrong. We've been talking to AMD over the last 6-9 months about having them fund some work to fix these issues, but I've finally heard that's not going to happen. They are looking at potentially doing the work in house. Although I'm happy to have people try to work the technical issues here, the best bet may be to talk directly to AMD about it. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Calculations for required RAM for sane DRI configurations.
On Tue, May 22, 2001 at 08:23:21AM -0600, Brian Paul wrote: Then, you should have at least a couple megabytes left over for the X pixmap cache and for OpenGL textures. Please realize these are important and significant parts of the calculation. For example, in the tdfx driver you can be using up to 1MB of command fifo, you can have 2048 lines (times the screen width) of offscreen pixmap cache, and basically whatever extra is used as textures. There may also be interesting alignment issues. Memory had to sit on 4k boundaries on the tdfx hardware. The driver tries to make intelligent choices, but sometimes they are difficult. Would you rather have offscreen pixmap memory which can be used for playing a video or have more texture memory which makes quake go faster? So, the calculation Brian listed is the minimum requirement for 3D to work in a given mode, but it isn't the maximum. Each board is different and may change as the code changes. You're not going to get one formula that says With ram X and depth Y your maximum resolution is Z - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Calculations for required RAM for sane DRI configurations.
On Tue, May 22, 2001 at 12:07:44PM -0400, Mike A. Harris wrote: I will try to report things here in the future. My idea was by doing it in the config tool, i could gage how things should be constrained, and then patch X to avoid allowing combinations that are unuseable. Well as a practical matter that may be the best bet. No one is paying us to support these old drivers, so you have no gaurantee of when or even if the bug will get fixed. We agree it should be fixed, but without more active developers it could take a while. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] v0.7 doesnt detect radeon ve
On Fri, May 18, 2001 at 10:22:14PM -0700, Joseph Carter wrote: On Fri, May 18, 2001 at 07:45:31PM -0400, Norbert Veber wrote: Change the line in your XF86Config file from Driver ati to Driver radeon Does that make a difference ? Yep, works now. Thanks for your help. Er, when did this change? I have been using ati all along here.. (There is currently a TNT2 in my box pending some change that may actually affect things..) Have I been using the wrong driver or something? The last driver I tried was somewhere around a couple of weeks ago. The way it is supposed to work is that you select ati and it automatically decides which of the lower level drivers to choose. If people are having to choose Radeon, then that means the automatic detection is failing somehow. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ANNOUNCE] v0.5 DRI release
On Thu, May 10, 2001 at 09:35:09PM +0200, Marcelo E. Magallon wrote: Daryll Strauss [EMAIL PROTECTED] writes: Actually, the SGI SI has all the man pages although not in their standard format. Since that does have a reasonable license I'll take a look at those and see if I can massage them into something XFree86 can use. For me it's enough with something like this: export ROOT=$(PWD)/debian/opengl-si make -C doc/man make -C doc/man install manpages get installed on $(ROOT)/usr/man/man3 The only thing that doesn't look that good are the eqn bits. The text formatter introduces too much whitespace, but that doesn't have anything to do with the original format of the manpages. Actually, as Alan already pointed out, the man pages were already added to the XFree tree, so we're all set. We should have opengl, glx, and glu pages in XFree 4.1. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ANNOUNCE] v0.5 DRI release
On Thu, May 10, 2001 at 09:59:17AM -0400, Allen Barnett wrote: I'm not sure if this package is intended for developers and on non-Debian systems, but I fearlessly tried it out on my RedHat 7.1 installation anyway. If I missed the point, please ignore the following. We have a bit of a problem with install scripts. Making them work for all the distributions is tough. We're trying to get there, but we need people to work on them. In reality the better way to install is to get a whole native package from your distribution. Our install scripts try to update that to the latest versions of our code. So if anyone wants to step up and help with the script issues on one or more distributions, please do! I tested the i386/tdfx combination on a 3500TV. Except for one problem, pure OpenGL apps run OK. I ran into a problem with the presence of /usr/lib/libGL.so from the RH 7.1 Mesa RPM installation. Unless you put LD_LIBRARY_PATH=/usr/X11R6/lib in the environment, all installed RH 7.1 OpenGL applications segmentation fault immediately in driMesaBindContext(). Perhaps the installation scripts should move the libraries in /usr/lib out of the way, too? Or at least ask the user about it? Otherwise, installed Mesa and Mesa-devel RPMs should probably be removed. In which case, it would be nice if the package included the Mesa header files, too. We've sort of assumed that this is more for users than developers which is why headers weren't included, but that's a reasonable suggestion. I thought we were moving the old libraries out of the way, but either we missed something or we're not doing that. Also, it appears that libGLU is the SGI SI? This is great! I tried relinking my own C++ application against libGL and libGLU in /usr/X11R6/lib. This yielded a couple of problems. First, either the installation script or ldconfig did not create a '/usr/X11R6/lib/libGLU.so' symlink to the real libGLU.so.1.3, therefore the linker picked up the one in /usr/lib (which is the Mesa 3.4 GLU in RH 7.1). [Here, I must admit ignorance. Perhaps someone would be willing to explain to me (off-line, maybe) exactly how ld, ld.so and ldconfig are supposed to interact with the version numbers on shared objects. What does ld look for that's different from what ld.so looks for, for example?] Yes, this is the SGI GLU. I added the symlink by hand and it linked OK. However, my program segmentation faults the first time it tries to do a dynamic_cast(). I suspect this results from using the RH 7.1 version of GCC 2.96. If I compile the SI GLU (which is a C++ library, itself) from the current Mesa CVS, my code works without problems. (I installed the RH 6.2 EGCS compatibility packages, too, and it got further, but my program uses Qt which is only available compiled with GCC 2.96, so it still aborts.) That's an ugly problem. C++ compiled under RH 6.2 is different that C++ compiled under RH 7.0 which is different than C++ compiled under RH 7.1. We're sort of stuck with this until GCC 3.0 is released with a new standard. The install script has the capability to handle architecture dependent packages, but we haven't gotten that far. Lastly, it would be nice if the OpenGL man pages where included, too (see ftp://ftp.sgi.com/opengl/doc). I would love to, but I haven't been able to get a straight answer out of anyone from SGI on the legal status of those pages. We can't take them until we know they aren't restricted by some copyright. I should try pinging them again and maybe we can get that into 4.1. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] G400 and blending
On Fri, May 04, 2001 at 08:19:44PM -0500, Andy Isaacson wrote: On Sat, May 05, 2001 at 01:32:07AM +1000, Gareth Hughes wrote: Adam K Kirchhoff wrote: Speaking of which, I've been thinking about ordering Tribes2 and was wondering if there are any issues that we should be aware of? Go and buy this game. It rocks. Loki has done a great job, and I'm working with them to make Linux T2 with the DRI the best combination to play with :-) Er, where?! I want to buy a Linux boxed version (no reason to add one to the beancounter's Windows column) but I can't find it anywhere. Am I out of luck? http://www.tuxgames.com Also LUGS who buy 10 or more can get a bulk discount and make arrangements directly with Loki. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVSUp access?
On Thu, May 03, 2001 at 10:09:46AM -0400, David Dawes wrote: On Wed, May 02, 2001 at 02:48:10PM -0500, Andy Isaacson wrote: Does the DRI project offer CVSUp access? I'm collecting CVS trees in the interest of being able to do speedy local CVS operations, and CVSUp is the most efficient method of getting the repository. It doesn't, but I'd like to see it available too. The DRI project is a regular SourceForge project, and CVSup access isn't a service provided with that. Make it a request to the sourceforge project. Perhaps it is something they can offer. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux Alpha Packages Online
On Tue, Apr 24, 2001 at 10:56:35PM +0100, Alan Hourihane wrote: On Mon, Apr 23, 2001 at 12:25:48PM +0100, Alan Hourihane wrote: I expect to have Alpha Linux packages online too, within the week. Alpha (compiled with -mcpu=ev5) Packages are now up too. -mcpu=ev56 would be a substantial improvement to performance. The only question is whether to not we'd leave any ev5 users out by doing that. My guess is that ev5 is so old and slow that no one is going to care about 3D graphics on it. As far as I know the only ev5 that was popular for linux was the old UMB systems and they're only as fast as an old pentium 166Mhz. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Information request
On Thu, Mar 29, 2001 at 07:35:14PM +0530, Damarugendra M wrote: I would like to know if I could use DRI to implement an application which obtains HW accleration and runs without using X11. that is i want to run this app from the console. this app may be a game or whatever. it should not be run on X or it should not be linked to any X librarys. It may use OpenGL for graphics. Then the first question you have to ask is whether you really should throw out X11. X11 does event handling, multiple windows, etc. It can also be made quite light weight. It's running in 600k on an IPAQ. If you decide you do need to throw out X, then you have to ask yourself if the DRI is the right solution for your problem. The DRI handles multiple 3D clients accessing hardware at the same time, sharing the same screen, in a robust and secure manner. If you don't need those properties the DRI isn't necessarily the right solution for you. If you get to this point, then it would be theoretically possible to remove the DRI from X11 and have it run without X11. There's no code to support that at this point, so it would require some significant work to do that. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
