Savage s3tc code
felix, thanks for the advice about the missing glxgears. had to do a full shutdown and powerup but everything is working fine now. i have attached a tarball of my savage driver code. as i mentioned before, this is from old code (works on 2.4 kernel). the changes are well documented just grep for "mcass". you can ignore the change in the function "savage_BCI_swap". this was a change that i made to the driver that is not opengl compliant, but gives my code a big speedup because of many small blits. so far i have tested the code with the savage4 and the twister. i think it should work with the savage pro. the twister and the savagepro use the same tiling constants foruncompressed texturesso hopefully the same will hold for compressed textures. if you have any questions just ask. mark SavageCodeS3TC.tgz Description: application/compressed
glxgears is blank on savage
savage driver team, when i run glxgears a window appears but nothing is displayed. the shell from which glxgears was run displays the usual frames per second and no other information. i checked glxinfo and dri is enabled. also found nothing unusual in the X log file. i have two options set "APGMode" to "4" and "AGPSize" to "32".i tried without using these options with the same result. the system is using the savage twister with 32 MB and AGP 4X. it is detected and reported as such in the X log file. the X server is running at 1280x1024 and using 16 bit color. what is strange is that this same code (no recompile, code was compiled on a intel based machine) works on another system i have. this other system is an AMD Athlon processor using a 32MB AGP 4X savage 4 video card. glxgears runs properly (i see gears spinning). i use the same settings for the x server and savage options asmentioned above. i have had dri working correctly in the past on the twister but it was way back in march of 2004. at that time it worked fine. the code i am using is from an earlier version (before the kernel 2.6, X org change over). i have to use the old driver that worksfor the linux 2.4 kernel (no choice, blame it on management). i think the version dates back to about May of 2004. if you have any ideas please let me know. thanks in advance, mark ps. some time ago i worked out the details for texture compression. i did not go as far as to include the 'on the fly' compression stuff. i have tested the loading of compressed textures and sub textures and both perform as expected. if you would like to include this in your latest stuff just let me know and i will post the source code files. all the files are commented quite clearly concerning the changes made.
texture units
guys, after reading documentation and looking in the code i noticed that the savage chip has two texture units. when does the second texture unit do its thing? i placed printfs in both sections of code (tex0 and tex1) and i only see the first unit doing anything. my test apps do not use multiple textures on a surface, is this what the second unit is for? mark
Re: savage texture compression - REALLY CLOSE
Felix, i have tried all tile formats. i get the same results using the 4 bit format as i do with the 32 bit format. in both of these formats the colors are correct but the image is warped. using the 16 bit format, the colors are wrong and the image is warped. using the 8 bit format the colors are wrong but the image isn't warped. i have also tried using different tile format values (tile size / sub tile size). the results vary but none so far have solved the problem. it seems that i a working with two variables. one, the format of the tiles. two, the size of the texture that is sent to the video card. if i knew one for sure then it would reduce some of the guessing. the easiest variable to answer should be the texture size as reported to the video card. suppose you have an image that's uncompressed, and has the dimensions 512x512 (in pixels). without compression, you would load the texture width and height registers with 9 and 9 repectively. 9 because 2^9 is 512 and the registers are loaded with the exponent. now compress the texture, what values do you put in the width and height registers? two possibilities are obvious. first, send the uncompressed dimensions, the video card is smart enough to deduce from the image format what the compressed dimensions should be. second, send the compressed dimensions. in the case of a DXT3 image this would be 11 and 7. could there be another logical set of values? only S3 knows! maybe someone from S3 or someone with technical documents for the savage chips could answer this question? thanks for listening. it's nice sometimes to organize my thoughts on paper, even if it only serves to define the problem. mark - Original Message - From: Felix Kühling [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Mark Cass [EMAIL PROTECTED] Sent: Saturday, May 15, 2004 2:28 PM Subject: Re: savage texture compression - REALLY CLOSE On Sat, 15 May 2004 13:30:16 -0700 Mark Cass [EMAIL PROTECTED] wrote: Felix, i think the texture formats you are talking about are the ones enumerated in savage_bci.h . i tried all of them. I was talking about the parameters that are used by the tiling functions for various texture formats. They are defined at the beginning of savagetex.c, called tileInfo_pro and tileInfo_s3d_s4. The first line applies to 4bit texture formats (supposedly the compressed ones). NEWS BULLETIN: i set the textBytes to 4 and i now have the correct colors. i think this works because each texel block (4x4 texels) in a DXT3 or DTX5 is compressed to a four byte value. but now the image looks warped! 4 bytes per 16 texels would make 2bit per texel. Weird, then why are these formats called xyz4bit? I'm not sure I understand what you mean with warped. Do you have a screenshot? mark Felix --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - REALLY CLOSE
Felix, i think the texture formats you are talking about are the ones enumerated in savage_bci.h . i tried all of them. NEWS BULLETIN: i set the textBytes to 4 and i now have the correct colors. i think this works because each texel block (4x4 texels) in a DXT3 or DTX5 is compressed to a four byte value. but now the image looks warped! mark - Original Message - From: Felix Kühling [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Mark Cass [EMAIL PROTECTED] Sent: Saturday, May 15, 2004 5:25 AM Subject: Re: savage texture compression - REALLY CLOSE Hi Mark, Your description of the problems sounds like the tiling code does the right thing. However, in the driver there were originally some constants for 4bit per pixel texture formats. I thought they were for compressed texture formats. For example one of the texture formats is named TFT_S3TC4Bit. There are now some guessed numbers in the tileInfo_*[0] for 4bit texture formats. They are completely untested as the driver didn't support any such texture formats so far. Have you tried playing with these? Felix On Fri, 14 May 2004 18:30:24 -0700 Mark Cass [EMAIL PROTECTED] wrote: guys, as i have mentioned before i am working on adding s3tc texture compression support to the savage driver. i have added code to the savage driver based upon the radeon driver (and patches). the code i have added only supports uploading pre-compressed textures. as also previously mentioned, i have tested the code and texture on a different computer that uses nvidia's driver and everything works. as it stands now, i have the compressed texture showing up but it does not look right. the colors are all messed up. the proportions and layout of the texture are correct. i set the size of the texture from the compressedSize variable in the texture struct. i set the width and height from the formulas in the radeon driver. width = (ImageWidthUncompressed / 4) x 16. height = ImageHeightUncompressed / 4. the 16 in the width formula is used for DXT3 and DXT5, 8 is used for DXT1. this width and height are used as input to the tile upload code, as well as inputs to the texture registers (width height in power of 2). i have tried using all possible internal formats for s3tc, as enumerated in savage_bci.h, but none make the picture look any better. in fact, most make it look worse so i think i have these right. i have also tried using a diffeerent bytes per texel which affects how the tiles are uploaded. currently i am using 1 byte per texel. it seems that the right amount of data is getting uploaded. i have played with the formulas (i.e. width and height just divided by 4 instead of the current disproportional values) and the texture appears distorted in proportion and composition. does anyone have an idea? mark | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=ick -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
savage texture compression - REALLY CLOSE
guys, as i have mentioned before i am working on addings3tc texture compression support to the savage driver. i have added code to the savage driver based upon the radeon driver (and patches). the code i have added only supports uploading pre-compressed textures. as also previously mentioned, i have tested the code and texture on a different computer that uses nvidia's driver and everything works. as it stands now, i have the compressed texture showing up but it does not look right. the colors are all messed up. the proportions and layout of the texture are correct. i set the size of the texture from the compressedSize variable in the texture struct. i set the width and height from the formulas in the radeon driver. width = (ImageWidthUncompressed / 4) x 16. height = ImageHeightUncompressed / 4. the "16" in the width formula is used for DXT3 and DXT5, "8" is used for DXT1. this width and height are used as input to the tile upload code, as well as inputs to the texture registers (width height in power of 2). i have tried using all possible internal formats for s3tc, as enumerated in savage_bci.h, but nonemake the picture look any better. in fact, most make it look worse so i think i have these right. i have also tried using a diffeerent bytes pertexel which affects how the tiles are uploaded. currently i am using 1 byte per texel. it seems that the rightamount of data is getting uploaded. i have played with the formulas (i.e. width and height just divided by 4 instead of the current disproportional values)and the texture appears distorted in proportion and composition. does anyone have an idea? mark
[Dri-devel] problems with compressed textures
developers, I am having experiancing a sementation fault when calling glCompressedTexImage2DARB. I have checked the pointer returned from GetProcAddress and it seems to be valid (not NULL). i placed a breakpoint in teximage.c (a mesa source file) on the function _mesa_CompressedTexImage2DARB. I am not getting to this mesa function before the segmentation fault. The debugger is giving me fits and i can not look at a backtrace to determine where the crash occurred. even loading a core dump yields no useful information. My question is what should i check? how do i determine if the pointer returned is actually the right one? is _mesa_CompressedTexImage2DARB is obviously not called directly by glCompressedTexImage2DARB, so how does it get called? this last question is related to flow, has does an opengl call in an application make it to the appropriate place in the driver? mark
[Dri-devel] debugging dri
guys, I am currently working onputtingtexture compression support into the savage driver. I am approaching this in two stages.Stage one is to get the loading of pre-compressed textures working. Stage two, would be the driver level compression of textures. I no there are possible legal limitations to stage two, so i plan to use the same methodology as the radeon driver. I have a plan,now i need to write some code. First I enabled the extensions GL_ARB_texture_compression andGL_EXT_texture_compression_s3tc.this was simple. The extensions are showing up when i run glxinfo. Next, I implemented the glCompressedTexImage2D function. After looking at the radeon driver it seems that this function is verysimiliar to the glTexImage2D function, so my savage version is very similiar to savageTexImage2D. i didn't expect this to work but it would provide a debugging point that i could later examine. Next, I added cases to ChooseTextureFormat for the DXT texture types. This was just a cut and paste job from the radeon driver. Last Change. In DDInitTextureFuncsI set the function pointerCompressedTexImage2D to the savage function created earlier. Now it was time for some testing. i built a sample application and tested it using another computer. the other computer is a linux box using the nvdia driver. After some debugging i transfered the test app over to my savage computer. This is where i ran into problems. The GetProcAddress function is returning valid pointers but as soon as glCompressedTexImage2D is called, the test application crashes. Well I obviously missed something! This is when i ran ddd on the test application. My idea was to step into glCompressedTexImage2D function until i found the point at which the crash occurred. One problem, I couldn't step into the function. I went back and rebuilt everything making sure the -g flag was set when compiling. still couldn't step into that function. Modified the test application to call glTexImage2D and couldn't step into it either. Enough background, now the questions. 1) Do i need to modify Mesa to implement the uploading of pre-compressed textures or should all of this take place in the savage driver? 2)Is it possilbe to step into the driver from a test application? If not,is there a way to useddd to debug a dri driver? any help would be greatly appreciated, mark
Re: [Dri-devel] debugging dri
Roland, thanks for the reply! i set a breakpoint on the glTexImage2D function then step in. backtrace shows nothing and the current source file is not opened. i tried manually opening the source file (savagetex.c in this case) and setting a breakpoint. ddd said 'savagetex.c is at address 0xsomeaddress but contains no code'. i set the breakpoint in the appropriate function and it did in fact break. i think i will try your idea of shutting off the optimizations. mark ps. i used a make World when doing the rebuild. - Original Message - From: Roland Scheidegger [EMAIL PROTECTED] To: Mark Cass [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 3:08 PM Subject: Re: [Dri-devel] debugging dri Mark Cass wrote: guys, I am currently working on putting texture compression support into the savage driver. I am approaching this in two stages. Stage one is to get the loading of pre-compressed textures working. Stage two, would be the driver level compression of textures. I no there are possible legal limitations to stage two, so i plan to use the same methodology as the radeon driver. I have a plan, now i need to write some code. First I enabled the extensions GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc. this was simple. The extensions are showing up when i run glxinfo. Next, I implemented the glCompressedTexImage2D function. After looking at the radeon driver it seems that this function is very similiar to the glTexImage2D function, so my savage version is very similiar to savageTexImage2D. i didn't expect this to work but it would provide a debugging point that i could later examine. Next, I added cases to ChooseTextureFormat for the DXT texture types. This was just a cut and paste job from the radeon driver. Last Change. In DDInitTextureFuncs I set the function pointer CompressedTexImage2D to the savage function created earlier. Sounds like a good plan. Maybe you need to adjust the upload functions too though. Now it was time for some testing. i built a sample application and tested it using another computer. the other computer is a linux box using the nvdia driver. After some debugging i transfered the test app over to my savage computer. This is where i ran into problems. The GetProcAddress function is returning valid pointers but as soon as glCompressedTexImage2D is called, the test application crashes. Well I obviously missed something! This is when i ran ddd on the test application. My idea was to step into glCompressedTexImage2D function until i found the point at which the crash occurred. One problem, I couldn't step into the function. I went back and rebuilt everything making sure the -g flag was set when compiling. still couldn't step into that function. Modified the test application to call glTexImage2D and couldn't step into it either. Stepping into glTexImage2D works just fine here. What exactly happens? Enough background, now the questions. 1) Do i need to modify Mesa to implement the uploading of pre-compressed textures or should all of this take place in the savage driver? No, modification of Mesa is not necessary. It has all code necessary to deal with compressed textures, save the code to actually compress/decompress them. 2) Is it possilbe to step into the driver from a test application? If not, is there a way to use ddd to debug a dri driver? I've used this a couple of times without doing anything special when compiling (you might want to get rid of -O2/-O3 though since gdb will miss the exact point where it crashed otherwise, and can show wrong function parameters, often it's more or less impossible to figure out why it really crashed when looking at a back trace). Though I've found the _mesa_test_os_sse_exception_support exception very useful (I always define breakpoints there, since you can't define driver-specific breakpoints before the application is run and has loaded x_dri.so). Did you rebuild everything (i.e. make World when building in the dri tree)? Sometimes the build system seems to miss updated files, and links together old and new files - all sort of weird errors can happen because of that (usually really odd crashes which look impossible to happen...). Roland --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now
[Dri-devel] annoying build problem
dri-devel, i am having a rebuild problem. not sure what the trigger is but here is the problem. i do a make World in /xc/xc and get an error related to HPkeysyms.h. make says it can't find the file. i copied all the header files into /xc/xc/include and that problem goes away, but then i get errors later in the compile. if i download fresh source code (remove my old xc/mesa tree) and rebuild everything is fine. has anyone had this problem? does anyone know how to fix it? mark
Re: [Dri-devel] savage : strange cursor problems
alex, the change option 2 seems to be working for the random noise cursor. the problem with the shimmer was related to refresh rate. when i turned down the refresh rate the shimmer went away. must be this video card, my old nvidia card had no problem with the old refresh rate. one other thing. i downloaded the latest code yesterday and built it. i am now noticing that the agp mode is only 1X. it used to be 4X. could you or somebody else point me in the right direction? thanks, mark - Original Message - From: Alex Deucher [EMAIL PROTECTED] To: Mark Cass [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 26, 2004 9:37 AM Subject: Re: [Dri-devel] savage : strange cursor problems --- Mark Cass [EMAIL PROTECTED] wrote: dri-devel, i am using the dri tree build (Mesa/xc - no branch) of all drivers (2d and 3d) on xfree86 version 4.3.0. my video card is a 32MB savage 4 pro. X is configured to use the savage drivers. the problems i am noticing concern the mouse/cursor. at all times the cursor seems to be shimmering. for example when the arrow cursor is displayed, the outline of the arrow looks like its moving/crawling. the second problem is that the cursor sometimes displays a large square (5x the size of the arrow cursor) of random noise. the cursor returns to normal when the mouse is dragged over a different window. this happens maybe once every 10 minutes. has anyone else seen this? felix said that alex had mentioned something about the problem at one point. At some point in the savage4 line, the cob index bitfield of the cob register changed. you card may be affected. There are two things you can try: 1. try the disableCOB option, however this will impact performance. 2. change psav-cobIndex from 7 to 2 in savage_driver.c if 2 fixes it it's gonna be tough to figure out when savage4s need a cobIndex of 7 and which need 2. perhaps we can figure out the revision and add that and check against it. we could also add a cobIndex override config option. Alex mark __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage : strange cursor problems
thanks alex. agp mode now 4x again. mark - Original Message - From: Alex Deucher [EMAIL PROTECTED] To: Mark Cass [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 26, 2004 2:11 PM Subject: Re: [Dri-devel] savage : strange cursor problems --- Mark Cass [EMAIL PROTECTED] wrote: alex, the change option 2 seems to be working for the random noise cursor. the problem with the shimmer was related to refresh rate. when i turned down the refresh rate the shimmer went away. must be this video card, my old nvidia card had no problem with the old refresh rate. Hmmm... how to deal with that cob...I'll look into that this weekend. one other thing. i downloaded the latest code yesterday and built it. i am now noticing that the agp mode is only 1X. it used to be 4X. could you or somebody else point me in the right direction? Yeah I added agpmode and agpsize options a few days again. the driver defaults to 1x. just add: Option AGPMode 4 to you config. you can also adjust the amount of AGP memory with the AGPSize option. right now it defaults to 16 MB. Alex thanks, mark - Original Message - From: Alex Deucher [EMAIL PROTECTED] To: Mark Cass [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 26, 2004 9:37 AM Subject: Re: [Dri-devel] savage : strange cursor problems --- Mark Cass [EMAIL PROTECTED] wrote: dri-devel, i am using the dri tree build (Mesa/xc - no branch) of all drivers (2d and 3d) on xfree86 version 4.3.0. my video card is a 32MB savage 4 pro. X is configured to use the savage drivers. the problems i am noticing concern the mouse/cursor. at all times the cursor seems to be shimmering. for example when the arrow cursor is displayed, the outline of the arrow looks like its moving/crawling. the second problem is that the cursor sometimes displays a large square (5x the size of the arrow cursor) of random noise. the cursor returns to normal when the mouse is dragged over a different window. this happens maybe once every 10 minutes. has anyone else seen this? felix said that alex had mentioned something about the problem at one point. At some point in the savage4 line, the cob index bitfield of the cob register changed. you card may be affected. There are two things you can try: 1. try the disableCOB option, however this will impact performance. 2. change psav-cobIndex from 7 to 2 in savage_driver.c if 2 fixes it it's gonna be tough to figure out when savage4s need a cobIndex of 7 and which need 2. perhaps we can figure out the revision and add that and check against it. we could also add a cobIndex override config option. Alex mark __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list
[Dri-devel] savage and clipping
dri-devel, i have been looking at the clipping issues with the savage driver. this centers around the use of the scissor box. currently the savage driver does not use the scissor box. next are my observations. i am new to this so please feel free to comment. i noticed that in the savgeDDRenderStart function the savageDDScissor function is called with thecoordinates of the first clip rect in the driDrawable. this effectively wiped out the value that was given by any previous calls to glScissor, hence no scissoring. i commented this command out and scissoring started working correctly well almost. it worked for the first call but did not work for subsequent calls. i found that subsequent calls were being held up in emitHWStateLocked. if the upload clip rects flag is not set and the flags for uploading ctx, textures or buffers are set then the registers are emitted and the scissor rect gets set. these conditions were not being met on the second call so the second attempt to set the scissor rect failed. to the conditions mentioned above, i added a check for scissor changed and now everything works. this is not a good solution, just a proof of concept. all the other drivers i have looked at don't seem to use the scissor rect to do general clipping. if i'm following the code, before they draw something they take the context clip rects and copy them into the sarea clip rects then execute the draw command. when draw command is executed the clip rects in the sarea are uploaded to the video card by the kernel driver. the savage kernel driver does not support uploading clip rects this is why they use the scissor rect. a proper implementation whether in the kernel driver or elsewhere would involve uploading the clip rects to the video card. i don't see any information on how to do this within savage driver code. i can't imagine that everyother video card has this capability and the savage doesn't. if someone knows of a source code sample please let me know. as things are now, i don't see any reason to intersect the scissor rect with the sarea clip rects. we draw to the back buffer, therefore we don't need to clip to overlapping windows. the scissor rect is intersected with the main draw region (window bounds) before it is uploaded to the video card, so we don't have to worry about drawing outside the draw region. of course this assumes that you only draw to the back buffer. as soon as you start drawing to the front buffer your gonna have problems. the swap buffer function does handle clipping properly. it uses the serea clip rects to define regions to blit to the front buffer. so no overlapping windows will be affected. now for a question. i don't know if it is in the opengl spec, but i would like to have the scissor rect taken into account during swap buffers. this is simple to implement. i think the i810 driver does something similar. this would provide a performance enhancement as the user would be able to control the amount of data blit'ed from the back buffer to the front buffer. most opengl optimization documentation mentions using the scissor rect to minimize drawing or clearing of unwanted regions, this seems to play directly into that strategy. please comment, mark
[Dri-devel] savage : strange cursor problems
dri-devel, i am using the dri tree build (Mesa/xc - no branch)of all drivers (2d and 3d) on xfree86 version 4.3.0. my video card is a 32MB savage 4 pro. X is configured to use the savage drivers. the problems i am noticing concern the mouse/cursor. at all times the cursor seems to be shimmering. for example when the arrow cursor is displayed, the outline of the arrow looks like its moving/crawling. the second problem is that the cursor sometimes displays a large square (5x the size of the arrow cursor) of random noise. the cursor returns to normal when the mouse is dragged over a different window. this happens maybe once every 10 minutes. has anyone else seen this? felix said that alex had mentioned something about the problem at one point. mark
[Dri-devel] savage and clipping
felix, the clipping problem i am seeing is one that you eluded to previuosly. it seems that when a textured object is drawn, the glSiccor rect is ignored. this is the clipping that i was referring to. sorry for being vague. i have run my test program on other hardware/driver combinations and they perform as expected. mark
[Dri-devel] ready to help with Savage driver
felix, i have been watching the dri developmentforum for a while. as you seem to be the person spearheading the savage 3d driver effort, i have directed this message to you. I am interested in this driver because the company i work for uses it on an embedded target. we do not use a powerful processor so every bit of performance we can get out of the video driver is important. I have been involved in software engineer for the past ten years. most of the work was done on a proprietary platform. the last two years have been on linux. i have studied the dri documentation and source code and now iwould like to write some code. the areas that i would like to look at first are clipping and the texture compression extension.are these difficult projects? can you point me in the right direction? i would also imagine that i will need to get documentation concerning the hardware. if you could pass along a contact i will get the ball rolling. our company buys large quantities of these chipsets so it shouldn't be any problem to get the documents, providing the right paper work is in order. thanks, mark
