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.Stepping into glTexImage2D works just fine here. What exactly happens?
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?
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.
I've used this a couple of times without doing anything special when2) 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?
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
