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=3149&alloc_id=8166&op=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, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
