[Dri-devel] Re: FXMesa
Daniel Borca wrote: Hi! I was just asking myself about the s and t factors in fxTexGetInfo. Why are they 256.0 limited? Is that enough for large textures? Voodoo 1 and 2 where limited to a maximum of 256x256 texture size. 'k, I know that! But when using large textures, should those factors scale accordingly? For example, TDFX already had large texture support when I saw it, but the factors were still 256.0... Hmm. This is getting into stuff I never really knew about. I wonder if there is anyone else out there in dri-devel or mesa-land that has an ongoing interest in the tdfx drivers? Keith --- 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] config branch merge schedule
Jos? Fonseca [EMAIL PROTECTED] wrote: Anyway, I'm now building a snapshot. If it succeeds please do a public request for testing on the dri-users and dri-devel. probably combined with a short list of common pitfalls ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Sep 30, 2003 at 02:43:17AM +0200, Michel Dänzer wrote: On Sun, 2003-09-28 at 18:03, Alan Hourihane wrote: On Sun, Sep 28, 2003 at 04:33:47PM +0200, Felix Kühling wrote: On Fri, 26 Sep 2003 10:26:40 -0700 Alan Hourihane [EMAIL PROTECTED] wrote: CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: [EMAIL PROTECTED] 03/09/26 10:26:40 Log message: no longer need radeon_pci.h since the XFree86 merge Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_driver.c Removed files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_pci.h Revision ChangesPath 1.64 +1 -1 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c After a cvs update -d and make World I get errors during compilation. radeon_pci.h is still included by radeon_dri.c and radeon_probe.c. Time to revive the file? No. I'm not quite sure why it was added in the first place, as these kinds of references should have been made to xf86PciInfo.h anyway. Didn't you get my rationale? Is this some kind of guessing game Michel ? I looked at your original commit message and it didn't give any reason why you did it in the first place. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-09-30 at 11:13, Alan Hourihane wrote: I looked at your original commit message and it didn't give any reason why you did it in the first place. I followed up to your commit, check out the dri-devel archives (and maybe check your filters? :) . I would have appreciated if you had asked before removing it to boot. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Sep 30, 2003 at 11:31:04AM +0200, Michel Dänzer wrote: On Tue, 2003-09-30 at 11:13, Alan Hourihane wrote: I looked at your original commit message and it didn't give any reason why you did it in the first place. I followed up to your commit, check out the dri-devel archives (and maybe check your filters? :) . I would have appreciated if you had asked before removing it to boot. Add it back if your that bothered. I'm not. Alan. --- 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] Mesa 5.1-6.0
On Tue, Sep 30, 2003 at 11:02:13AM +0100, Alan Hourihane wrote: Is it worth moving the remaining DRI drivers into Mesa for the 6.0 release ? It seems as though mga, r128, r200 and radeon are already there. Actually, Do it this way we can fork the drivers for the Mesa 6.0 release and get them updated, while leaving the DRI tree at Mesa 5.0.2 ready for bug fixes to be merged back into XFree86 ready for a stable release of XFree86. Alan. --- 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] config branch merge schedule
On Tue, Sep 30, 2003 at 12:24:53AM +0100, José Fonseca wrote: Anyway, I'm now building a snapshot. If it succeeds please do a public request for testing on the dri-users and dri-devel. Just to let you know that the config snapshots built without any incident. Regards, José Fonseca PS: For general information, the HEAD failed to build somehere in the SiS driver. And the s3virge seems to have the missing-newline-at-eof problem somewhere. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Alan Hourihane wrote: On Tue, Sep 30, 2003 at 11:31:04AM +0200, Michel Dänzer wrote: On Tue, 2003-09-30 at 11:13, Alan Hourihane wrote: I looked at your original commit message and it didn't give any reason why you did it in the first place. I followed up to your commit, check out the dri-devel archives (and maybe check your filters? :) . I would have appreciated if you had asked before removing it to boot. Add it back if your that bothered. I'm not. Martin, can you repost your orignal email? I'd like to have one approach which is agreed by all parties and this back forth isn't going anywhere... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mesa 5.1-6.0
Is it worth moving the remaining DRI drivers into Mesa for the 6.0 release ? It seems as though mga, r128, r200 and radeon are already there. Alan. --- 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] config branch merge schedule
José Fonseca wrote: On Tue, Sep 30, 2003 at 12:24:53AM +0100, José Fonseca wrote: Anyway, I'm now building a snapshot. If it succeeds please do a public request for testing on the dri-users and dri-devel. Just to let you know that the config snapshots built without any incident. Regards, José Fonseca PS: For general information, the HEAD failed to build somehere in the SiS driver. And the s3virge seems to have the missing-newline-at-eof problem somewhere. What is the status of the s3virge driver? If it's only half working and now not compiling, I think we should disable it. Keith --- 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] Mesa 5.1-6.0
Alan Hourihane wrote: On Tue, Sep 30, 2003 at 11:02:13AM +0100, Alan Hourihane wrote: Is it worth moving the remaining DRI drivers into Mesa for the 6.0 release ? It seems as though mga, r128, r200 and radeon are already there. Actually, Do it this way we can fork the drivers for the Mesa 6.0 release and get them updated, while leaving the DRI tree at Mesa 5.0.2 ready for bug fixes to be merged back into XFree86 ready for a stable release of XFree86. That sounds good to me. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] s3virge (Was: config branch merge schedule)
On Tue, Sep 30, 2003 at 11:16:54AM +0100, Keith Whitwell wrote: José Fonseca wrote: On Tue, Sep 30, 2003 at 12:24:53AM +0100, José Fonseca wrote: PS: For general information, the HEAD failed to build somehere in the SiS driver. And the s3virge seems to have the missing-newline-at-eof problem somewhere. What is the status of the s3virge driver? If it's only half working and now not compiling, I think we should disable it. I wasn't quite clear on that - the s3virge only lives on its own branch (s3virge-0-0-1-branch) so there is nothing to disable. IIRC its state is that it's missing some GL functionality, and I don't think the security issue was even touted. See http://dri.sourceforge.net/snapshots/bleeding-edge/README.s3virge for more info. Actually, after more cerfull inspection, it appears that the build problem with the s3virge is that the branch is getting too far behind to correctly build with the X 4.3.0 sources... Have to look deeper though. It would be nice to keep the old drivers available. We should start doing 3D SDKs for each major XFree86 version, so that as the infrastucture (DRM, Mesa) gets _source-wise_ incompatible, we can still build the old drivers which ware _binary-wise_ compatible with recent X versions. I know XFree86 has a driver SDK already. Does anybody have an idea whether we could extend it for 3D? José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: s3virge (Was: config branch merge schedule)
José Fonseca wrote: On Tue, Sep 30, 2003 at 11:16:54AM +0100, Keith Whitwell wrote: José Fonseca wrote: On Tue, Sep 30, 2003 at 12:24:53AM +0100, José Fonseca wrote: PS: For general information, the HEAD failed to build somehere in the SiS driver. And the s3virge seems to have the missing-newline-at-eof problem somewhere. What is the status of the s3virge driver? If it's only half working and now not compiling, I think we should disable it. I wasn't quite clear on that - the s3virge only lives on its own branch (s3virge-0-0-1-branch) so there is nothing to disable. OK, no worries then. ... It would be nice to keep the old drivers available. We should start doing 3D SDKs for each major XFree86 version, so that as the infrastucture (DRM, Mesa) gets _source-wise_ incompatible, we can still build the old drivers which ware _binary-wise_ compatible with recent X versions. I know XFree86 has a driver SDK already. Does anybody have an idea whether we could extend it for 3D? I think that there is a forwards compatibility (4.1 modules work with 4.3) but not vice versa. I agree it's a good goal. Keith --- 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] config branch merge schedule
José, Thanks for getting the config snapshots working again. I just downloaded the latest one for radeon (radeon-config-20030930-linux.i386.tar.bz2). I can't test it on my notebook now, I'll do that when I get home. I just noticed that xdriinfo is still missing. There is even a manpage you could include in the snapshot. :) And I saw lots of tdfx-config snapshots. They are not needed, the tdfx driver doesn't support configuration yet. Regards, Felix On Tue, 30 Sep 2003 11:10:25 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2003 at 12:24:53AM +0100, José Fonseca wrote: Anyway, I'm now building a snapshot. If it succeeds please do a public request for testing on the dri-users and dri-devel. Just to let you know that the config snapshots built without any incident. Regards, José Fonseca PS: For general information, the HEAD failed to build somehere in the SiS driver. And the s3virge seems to have the missing-newline-at-eof problem somewhere. __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] config branch merge schedule
On Tue, 30 Sep 2003 13:00:16 +0200 Felix Kühling [EMAIL PROTECTED] wrote: José, Thanks for getting the config snapshots working again. I just downloaded the latest one for radeon (radeon-config-20030930-linux.i386.tar.bz2). I can't test it on my notebook now, I'll do that when I get home. I just noticed that xdriinfo is still missing. There is even a manpage you could include in the snapshot. :) Forget that, I should have read README.config :-/. Still it would be nice to include xdriinfo in the snapshot. It's quite small, so there's no real need for a separate package. The install script has a mechanism to run a custom script in an extras-subdir that could install xdriinfo and a manpage to the appropriate places. And I saw lots of tdfx-config snapshots. They are not needed, the tdfx driver doesn't support configuration yet. The same for i810 and i830. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] config branch merge schedule
On Tue, Sep 30, 2003 at 01:06:58PM +0200, Felix Kühling wrote: On Tue, 30 Sep 2003 13:00:16 +0200 Felix Kühling [EMAIL PROTECTED] wrote: José, Thanks for getting the config snapshots working again. I just downloaded the latest one for radeon (radeon-config-20030930-linux.i386.tar.bz2). I can't test it on my notebook now, I'll do that when I get home. I just noticed that xdriinfo is still missing. There is even a manpage you could include in the snapshot. :) Forget that, I should have read README.config :-/. Still it would be nice to include xdriinfo in the snapshot. It's quite small, so there's no real need for a separate package. The install script has a mechanism to run a custom script in an extras-subdir that could install xdriinfo and a manpage to the appropriate places. I'd generally agree with you. The problem is automating that without breaking the other snapshots - it'll take some work plus the risk of breaking the snapshots - so I'm not inclined to doit myself. But if you care enough to download the scripts in http://dri.sourceforge.net/snapshots/scripts/ and make a patch to dripkg.sh (and possibly package.sh) to do what you say I'll gladly welcome it... And I saw lots of tdfx-config snapshots. They are not needed, the tdfx driver doesn't support configuration yet. The same for i810 and i830. Ok. Deleted and disabled those. José Fonseca --- 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] s3virge (Was: config branch merge schedule)
unless someone beats me to it, I was planning on messing with the virge driver at some point going forward. I got a hold of the Duoview info from the virge databook, so I'm planning to add support for dualhead and probably mergedfb. after that I'll mess with the 3D driver. (does anyone know if there are databooks for the 3D stuff available anywhere? I heard that S3 released the virge databooks without an NDA. Also I seem to recall an SDK being available...) There are quite a few things on my plate right now (textured video for radeon, genericisizing mergedfb, etc.) though so I'm not sure when I'll get to it. plus I need to pick up an old virge mx first. Alex --- Jos� Fonseca [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2003 at 11:16:54AM +0100, Keith Whitwell wrote: Jos� Fonseca wrote: On Tue, Sep 30, 2003 at 12:24:53AM +0100, Jos� Fonseca wrote: PS: For general information, the HEAD failed to build somehere in the SiS driver. And the s3virge seems to have the missing-newline-at-eof problem somewhere. What is the status of the s3virge driver? If it's only half working and now not compiling, I think we should disable it. I wasn't quite clear on that - the s3virge only lives on its own branch (s3virge-0-0-1-branch) so there is nothing to disable. IIRC its state is that it's missing some GL functionality, and I don't think the security issue was even touted. See http://dri.sourceforge.net/snapshots/bleeding-edge/README.s3virge for more info. Actually, after more cerfull inspection, it appears that the build problem with the s3virge is that the branch is getting too far behind to correctly build with the X 4.3.0 sources... Have to look deeper though. It would be nice to keep the old drivers available. We should start doing 3D SDKs for each major XFree86 version, so that as the infrastucture (DRM, Mesa) gets _source-wise_ incompatible, we can still build the old drivers which ware _binary-wise_ compatible with recent X versions. I know XFree86 has a driver SDK already. Does anybody have an idea whether we could extend it for 3D? Jos� Fonseca --- 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 __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] BlockHandler with radeon r128
Does anyone know why the radeon r128 drivers call FLUSH_RING when in the BlockHandler ? Alan. --- 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] BlockHandler with radeon r128
Alan Hourihane wrote: Does anyone know why the radeon r128 drivers call FLUSH_RING when in the BlockHandler ? No -- seems unnecessary. Perhaps a hangover from the days when 2D accel was disabled with dri? Keith --- 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] BlockHandler with radeon r128
On Tue, 2003-09-30 at 15:58, Alan Hourihane wrote: Does anyone know why the radeon r128 drivers call FLUSH_RING when in the BlockHandler ? This is the best way to ensure that the indirect buffer gets flushed according to Mark Vojkovich. Without it, drawing operations could get stuck in the indirect buffer for quite a while. See the dri-devel archives. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- 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] BlockHandler with radeon r128
Michel Dnzer wrote: On Tue, 2003-09-30 at 15:58, Alan Hourihane wrote: Does anyone know why the radeon r128 drivers call FLUSH_RING when in the BlockHandler ? This is the best way to ensure that the indirect buffer gets flushed according to Mark Vojkovich. Without it, drawing operations could get stuck in the indirect buffer for quite a while. See the dri-devel archives. Ah, yes. What's confusing here is the naming of the macro: FLUSH_RING() doesn't actually have anything to do with the ring, but rather sends the buffer of commands being built up in the X server off to the kernel. Perhaps renaming the macro to FLUSH_INDIRECT_BUFFER() would help make things clearer? Keith --- 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] BlockHandler with radeon r128
On Tue, Sep 30, 2003 at 04:20:23PM +0100, Keith Whitwell wrote: Michel Dänzer wrote: On Tue, 2003-09-30 at 15:58, Alan Hourihane wrote: Does anyone know why the radeon r128 drivers call FLUSH_RING when in the BlockHandler ? This is the best way to ensure that the indirect buffer gets flushed according to Mark Vojkovich. Without it, drawing operations could get stuck in the indirect buffer for quite a while. See the dri-devel archives. Ah, yes. What's confusing here is the naming of the macro: FLUSH_RING() doesn't actually have anything to do with the ring, but rather sends the buffer of commands being built up in the X server off to the kernel. Perhaps renaming the macro to FLUSH_INDIRECT_BUFFER() would help make things clearer? Sounds good. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeon Transition functions
In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Firewalled (Was: Weekly IRC meeting reminder)
On Tue, Sep 30, 2003 at 12:32:08AM +0100, José Fonseca wrote: Anybody knows if there is any way around firewalled IRC port? As this is (hopefully) my last PhD year I've decided to spend most of my time in the university and dropped internet home. I'd like to assist the IRC meetings but unfortunatly my university blocks the IRC port. I once asked IT support to open it up for me, but they close it again. That's why I'm wondering if there is any way to access the freenode.net network in another port before relying on IT support once again. My google searches on this subject have been unsuccessful so far... Thanks, José Fonseca Thanks to everybody who replied, both publically and privately. I'll follow your suggestions and see what can be done. Thanks again, Jose Fonseca --- 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] radeon Transition functions
W licie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. Hi These are used used by 3D driver back depth/stencil buffers and texture memory. This memory is reserved so it wont get overwritten by 2D driver. It is used by means of RADEONInfoRec::frontOffset, RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. BTW: As I'am working on stereo now I need to allocate additional buffers for left eye buffers. Currently I allocate them whenever TransitionTo3D is called, but I think it would be quite useful if I would add TransitionToStereo/Mono functions and allocate/free them then. I looked at DRICreatedrawable code but I have no clue how to check whether drawable is stereo (if it does make sense). I think I can do it by checking Visual, but no clue how to get it. Can someone give me some clues. -- Jacek Rosik [EMAIL PROTECTED] --- 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] radeon Transition functions
On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. Hi These are used used by 3D driver back depth/stencil buffers and texture memory. This memory is reserved so it wont get overwritten by 2D driver. It is used by means of RADEONInfoRec::frontOffset, RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. Not from what I can see. The allocation of back, depth/stencil is done in radeon_driver.c before passing what's left onto the FBManager. These areas are pointed to by info-backOffset, info-depthOffset and info-textureOffset. I don't see what purpose info-backArea and info-depthTexArea have. BTW: As I'am working on stereo now I need to allocate additional buffers for left eye buffers. Currently I allocate them whenever TransitionTo3D is called, but I think it would be quite useful if I would add TransitionToStereo/Mono functions and allocate/free them then. I looked at DRICreatedrawable code but I have no clue how to check whether drawable is stereo (if it does make sense). I think I can do it by checking Visual, but no clue how to get it. Can someone give me some clues. Look in the CreateContext routines to see how to check visuals. Alan. --- 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] radeon Transition functions
W licie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. Hi These are used used by 3D driver back depth/stencil buffers and texture memory. This memory is reserved so it wont get overwritten by 2D driver. It is used by means of RADEONInfoRec::frontOffset, RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. Not from what I can see. The allocation of back, depth/stencil is done in radeon_driver.c before passing what's left onto the FBManager. These areas are pointed to by info-backOffset, info-depthOffset and info-textureOffset. These offsets are only calculated. Only front buffer area is allocated, rest is left to be allocated only on demand. Memory manager is initialised to maximum possible memory then area for framebuffer is reserved. Lines necessary for other buffers is only calculated. (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 I don't see what purpose info-backArea and info-depthTexArea have. Believe me, recently I had quite a few chances to see contents of these areas and normally they are used by 2D apps (mainly XMMS ;)). So if we wont reserve them screen corruption may occur. BTW: As I'am working on stereo now I need to allocate additional buffers for left eye buffers. Currently I allocate them whenever TransitionTo3D is called, but I think it would be quite useful if I would add TransitionToStereo/Mono functions and allocate/free them then. I looked at DRICreatedrawable code but I have no clue how to check whether drawable is stereo (if it does make sense). I think I can do it by checking Visual, but no clue how to get it. Can someone give me some clues. Look in the CreateContext routines to see how to check visuals. Alan. THX Another question: Is there any reason why memory manager is initialised to pScrn-displayWidth width? Can it be allocated to pScrn-displayWidth*2? I know it must fit 8192x8192 area for radon. -- Jacek Rosik [EMAIL PROTECTED] --- 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] radeon Transition functions
On Tue, Sep 30, 2003 at 07:54:00PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. Hi These are used used by 3D driver back depth/stencil buffers and texture memory. This memory is reserved so it wont get overwritten by 2D driver. It is used by means of RADEONInfoRec::frontOffset, RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. Not from what I can see. The allocation of back, depth/stencil is done in radeon_driver.c before passing what's left onto the FBManager. These areas are pointed to by info-backOffset, info-depthOffset and info-textureOffset. These offsets are only calculated. Only front buffer area is allocated, rest is left to be allocated only on demand. Memory manager is initialised to maximum possible memory then area for framebuffer is reserved. Lines necessary for other buffers is only calculated. (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 I don't see what purpose info-backArea and info-depthTexArea have. Believe me, recently I had quite a few chances to see contents of these areas and normally they are used by 2D apps (mainly XMMS ;)). So if we wont reserve them screen corruption may occur. No they're not. The memory IS allocated because the FBManager is never given it. This is what happens. The front buffer is allocated at the top of video memory. Then some texture memory is grabbed at the bottom of video memory depending on the amount of video ram available. Next, we grab a chunk for the depth buffer and finally for the back buffer. Then if there's more than 8191 scanlines still available we pass a maximum of 8191 off to the FBManager to manage for us. This is what's used by Xv. BTW: As I'am working on stereo now I need to allocate additional buffers for left eye buffers. Currently I allocate them whenever TransitionTo3D is called, but I think it would be quite useful if I would add TransitionToStereo/Mono functions and allocate/free them then. I looked at DRICreatedrawable code but I have no clue how to check whether drawable is stereo (if it does make sense). I think I can do it by checking Visual, but no clue how to get it. Can someone give me some clues. Look in the CreateContext routines to see how to check visuals. Alan. THX Another question: Is there any reason why memory manager is initialised to pScrn-displayWidth width? Can it be allocated to pScrn-displayWidth*2? I know it must fit 8192x8192 area for radon. Is there some requirement that you have to have both stereo buffers next to each other and increase the displayWidth ?? You'd screw up the accelerator normally by doing this, but I don't know what the requirements are for stereo. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: branch 4 cle266 (Was: good news for savage users or not ???)
On Maw, 2003-09-30 at 00:51, Jos Fonseca wrote: The tar ball of the via gl directory can be found at. http://www.linux.org.uk/~alan/via-gl.tar.gz and is hopefully useful for building a proper via branch in CVS. Alan, I know you're planning in going to do a sabatical. Do u plan to do more work on this or will it also be halted for that period? In the later case, is that still the most recent tarball? It is. And having just started the MBA course its looking like my time to hack on it will be rather limited. So we teach the undergraduates this bit in twelve weeks, you've got two.. Alan --- 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] radeon Transition functions
Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. Hi These are used used by 3D driver back depth/stencil buffers and texture memory. This memory is reserved so it wont get overwritten by 2D driver. It is used by means of RADEONInfoRec::frontOffset, RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. Not from what I can see. The allocation of back, depth/stencil is done in radeon_driver.c before passing what's left onto the FBManager. These areas are pointed to by info-backOffset, info-depthOffset and info-textureOffset. These offsets are only calculated. Only front buffer area is allocated, rest is left to be allocated only on demand. Memory manager is initialised to maximum possible memory then area for framebuffer is reserved. Lines necessary for other buffers is only calculated. This is my understanding also. We used to statically allocate the buffers, but Mark V. changed it so the driver frees the memory for use as pixmap cache/whatever when there are no active 3d contexts. This is less good in some respects than dynamically allocated private back and depth buffers, but it has the nice effect of not crippling 2d when 3d is not active. Keith --- 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] radeon Transition functions
On Tue, Sep 30, 2003 at 07:35:46PM +0100, Alan Hourihane wrote: On Tue, Sep 30, 2003 at 07:54:00PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. Hi These are used used by 3D driver back depth/stencil buffers and texture memory. This memory is reserved so it wont get overwritten by 2D driver. It is used by means of RADEONInfoRec::frontOffset, RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. Not from what I can see. The allocation of back, depth/stencil is done in radeon_driver.c before passing what's left onto the FBManager. These areas are pointed to by info-backOffset, info-depthOffset and info-textureOffset. These offsets are only calculated. Only front buffer area is allocated, rest is left to be allocated only on demand. Memory manager is initialised to maximum possible memory then area for framebuffer is reserved. Lines necessary for other buffers is only calculated. (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 I don't see what purpose info-backArea and info-depthTexArea have. Believe me, recently I had quite a few chances to see contents of these areas and normally they are used by 2D apps (mainly XMMS ;)). So if we wont reserve them screen corruption may occur. No they're not. The memory IS allocated because the FBManager is never given it. This is what happens. The front buffer is allocated at the top of video memory. Then some texture memory is grabbed at the bottom of video memory depending on the amount of video ram available. Next, we grab a chunk for the depth buffer and finally for the back buffer. Then if there's more than 8191 scanlines still available we pass a maximum of 8191 off to the FBManager to manage for us. This is what's used by Xv. O.k. I've got it. I can see that scanlines is calculated from the total FbMapSize and not the remaining after static allocation. But what I still don't understand properly is how can we guarantee that the backOffset etc, that is passed to the kernel module and backArea which is allocated dynamically are pointing to the same location when transitioning ? Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Announcement] config-0-0-1-branch needs testers
Hi all, the work on the new configuration infrastructure has come quite far in the last months but has got very little testing so far. I attached a short HOWTO document about how to obtain, install and test the config-0-0-1-branch, either from CVS or binary snapshots. The following drivers support the new configuration infrastructure: mga, r128, r200, radeon. You may be disappointed by the little number of options escpecially in the mga and r128 drivers. One reason is that many old boolean options were summarized in a few enumeration options. The number of options is expected to grow after the branch has been merged. Also more drivers are going to adopt the new configuration system. However, before we feel confident enough to merge the branch we need more feedback. So please test it, your feedback is very welcome. Best regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. DRI config-0-0-1-branch HOWTO Felix Kühling (fxkuehl at gmx dot de) 30 September 2003 = 1 Introduction 2 Obtaining and Installation 2.1 CVS 2.2 Snapshots 3 Testing and Trouble-Shooting 3.1 Testing the Installation 3.1.1 The driver supports configuration 3.1.2 xdriinfo is installed correctly and libGL.so was updated 3.2 Example Configurations 4 Graphical Configuration Appendix A: Example Configuration File --- 1 Introduction -- On the config-0-0-1-branch the development of a new configuration infrastructure for DRI is taking place. It introduces a consistent mechanism for configuring all DRI drivers using a XML-based configuration file and an interface for configuration GUIs to find out about the configuration options of installed drivers. Option descriptions are available in multiple languages, german and english so far. A first graphical configuration tool written in Python and Gtk+ is also available. This document is a brief guide how to obtain, install and test the config-0-0-1-branch. A technical design document can be found at http://user.cs.tu-berlin.de/~felixyz/dri/dri_config_design_rev4.html 2 Obtaining and Installation 2.1 CVS You can download the source code via anonymous CVS and compile it yourself. Checkout the source code from the config-0-0-1-branch on dri.freedesktop.org: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co -r config-0-0-1-branch xc See http://dri.freedesktop.org/Software/DRIanoncvs for more details. Compile and install the source. See http://dri.sourceforge.net/doc/DRIcompile.html for details. If you changed the ProjectRoot directory in xc/config/cf/host.def make sure that $ProjectRoot/bin is in your $PATH. 2.2 Snapshots There are now binary snapshots of the config-0-0-1-branch for linux in http://dri.sourceforge.net/snapshots/bleeding-edge/: mga-config-*-linux.i386.tar.bz2 r200-config-*-linux.i386.tar.bz2 radeon-config-*-linux.i386.tar.bz2 rage128-config-*-linux.i386.tar.bz2 The other drivers don't support the new configuration infrastructure yet. To install a snapshot unpack the archive and run the contained install.sh script as root: tar -xjf driver-config-date-linux.i386.tar.bz2 cd dripkg ./install.sh Follow the instructions on the screen. You also need to install xdriinfo somewhere in your binary search path, e.g. /usr/local/bin. It can be downloaded bzip2 compressed from http://dri.sourceforge.net/snapshots/extras/xdriinfo.bz2. 3 Testing and Trouble-Shooting -- 3.1 Testing the Installation 3.1.1 The driver supports configuration Run LIBGL_DEBUG=true glxinfo Among other messages you should see error messages that /etc/drirc and $HOME/.drirc were not found e.g.: libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/felix/.drirc: No such file or directory. These messages are harmless but they indicate that the driver actually supports configuration. 3.1.2 xdriinfo is installed correctly and libGL.so was updated Run xdriinfo You should see a list of all screens on your display with their DRI driver names e.g.: Screen 0: radeon Run xdriinfo options yourdriver You should see a XML-document that describes the options supported by your driver. This document is primarily intended to inform configuration GUIs about available options. 3.2 Example Configurations In the appendix you find an example configuration file that lists all current options of all drivers with their default values. You can install it in $HOME/.drirc and start changing the configuration from there. You can make sections in the configuration file that refer only to one specific
[Dri-devel] Re: branch 4 cle266 (Was: good news for savage users or not ???)
On Tue, Sep 30, 2003 at 09:08:58PM +0100, Alan Cox wrote: On Maw, 2003-09-30 at 00:51, José Fonseca wrote: The tar ball of the via gl directory can be found at. http://www.linux.org.uk/~alan/via-gl.tar.gz and is hopefully useful for building a proper via branch in CVS. Alan, I know you're planning in going to do a sabatical. Do u plan to do more work on this or will it also be halted for that period? In the later case, is that still the most recent tarball? It is. And having just started the MBA course its looking like my time to hack on it will be rather limited. OK. I've imported your tarball plus the 2D and DRM driver from VIA's original one. For anybody interested, it still requires some manual editing of some makefiles before it compiles but I wanted to commit what I have so far. So we teach the undergraduates this bit in twelve weeks, you've got two.. I'm sure they only want you to not get bored! ;-) Regards, José Fonseca --- 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] radeon Transition functions
Alan Hourihane wrote: On Tue, Sep 30, 2003 at 07:35:46PM +0100, Alan Hourihane wrote: On Tue, Sep 30, 2003 at 07:54:00PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: W licie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory allocation going on for info-backArea and info-depthTexArea. The trouble is - I can't see anywhere where these allocations are actually used. Are these leftovers ?? Alan. Hi These are used used by 3D driver back depth/stencil buffers and texture memory. This memory is reserved so it wont get overwritten by 2D driver. It is used by means of RADEONInfoRec::frontOffset, RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. Not from what I can see. The allocation of back, depth/stencil is done in radeon_driver.c before passing what's left onto the FBManager. These areas are pointed to by info-backOffset, info-depthOffset and info-textureOffset. These offsets are only calculated. Only front buffer area is allocated, rest is left to be allocated only on demand. Memory manager is initialised to maximum possible memory then area for framebuffer is reserved. Lines necessary for other buffers is only calculated. (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 I don't see what purpose info-backArea and info-depthTexArea have. Believe me, recently I had quite a few chances to see contents of these areas and normally they are used by 2D apps (mainly XMMS ;)). So if we wont reserve them screen corruption may occur. No they're not. The memory IS allocated because the FBManager is never given it. This is what happens. The front buffer is allocated at the top of video memory. Then some texture memory is grabbed at the bottom of video memory depending on the amount of video ram available. Next, we grab a chunk for the depth buffer and finally for the back buffer. Then if there's more than 8191 scanlines still available we pass a maximum of 8191 off to the FBManager to manage for us. This is what's used by Xv. O.k. I've got it. I can see that scanlines is calculated from the total FbMapSize and not the remaining after static allocation. But what I still don't understand properly is how can we guarantee that the backOffset etc, that is passed to the kernel module and backArea which is allocated dynamically are pointing to the same location when transitioning ? I don't know enough about the XFree86 offscreen memory manager, but that's they intention of the code - to temporarily give back the 3D buffers for use as pixmaps/whatever for the period while no 3d contexts are active. The trick seems to work - but I can't tell you why exactly. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: branch 4 cle266 (Was: good news for savage users or not ???)
It might be better to import the 2D driver from xfree86 CVS since there have been some major changes and fixes since the original release. see bugzilla: http://bugs.xfree86.org/show_bug.cgi?id=525 Alex --- José Fonseca [EMAIL PROTECTED] wrote: OK. I've imported your tarball plus the 2D and DRM driver from VIA's original one. For anybody interested, it still requires some manual editing of some makefiles before it compiles but I wanted to commit what I have so far. So we teach the undergraduates this bit in twelve weeks, you've got two.. I'm sure they only want you to not get bored! ;-) Regards, José Fonseca __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
