Ati, OpenGL and ATI2N

[Schmackbolzen]

Starting with driver Catalyst 9.4 I am not able to use the ATI2N texture format anymore, the program just crashes as soon as i try to bind the texture in the shader. Can anyone give me a hint, how to solve this?

I also was wondering about this line:

Code Select Expand


GLInternal := GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT;
if not Caps.LATCCompression and Caps.ATI3DcCompression then
          GLInternal := GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI;   
Shall I conclude, that GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT is superior than GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI?

Thanks in advance!

[Galfar]

What ATI card do you have? I've got Radeon 4850 and it works there. 

GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT is the same format as 3Dc but on NVidia DirectX 10 cards (as 3Dc is required feature of D3D10). I guess I just put it there first because it is EXT extension, not only vendor specific. 

[Schmackbolzen]

Thanks for the answer!

I'm not sure what I am facing here, atm. it looks like when I create a normal lazarus GUI application it works, but as soon as i create a freepascal program it crashes. Even if I change the compilerswitch to {$apptype GUI} I get crashes. I created 2 similar projects, one as Application and one as Console Application and even though the difference is absolutely minimal only the standard lazarus application with forms works.

I have two Ati cards (4850 and 4570 mobility), both the same behaviour (and on both it runs with catalyst 9.3).

Asm of the crashing location:

Code Select Expand


fstps (%edx) <- debugger says it crashes here
mov 0x10(%eax),%ecx
test %ecx,%ecx
jbe 0x262d03c <atioglxx!atiPPHSN+1576764>


I sould mention that I tested on windows Vista and windows xp64.

Thanks for any help!

[Galfar]

That's really strange. 
Try asking this in Lazarus/FPC forum too.
Maybe also look at what compiler switches Laz application and console app use and try to isolate the one which causes problems (if there is any).

[Schmackbolzen]

The thing is, when I disable ATI2N and let the loader use ifA8Gray8, everything works as it should. Thats what I don't get...

[Galfar]

Hmm not sure now which loader you mean.
Why it would be strange that A8Gray8 format works and ATI2N doesn't? 

[Schmackbolzen]

I simply changed

Code Select Expand

if (Desired = ifATI2N) and not (Caps.ATI3DcCompression or Caps.LATCCompression) then
      Desired := ifA8Gray8;
to

Code Select Expand


if (Desired = ifATI2N) and (Caps.ATI3DcCompression or Caps.LATCCompression) then
      Desired := ifA8Gray8;
in ImagingOpenGL.pas, starting line 621
and I dont get crashes. The next thing I will test is trying to load directly from file, maybe I messed something up in the loading process, but on the other hand why does it work with grayscale image format...

[Galfar]

A8Gray8 works because later in CreateGLTextureFromMultiImage procedure image is converted to this format (if your modification is used). So there is no ATI2N usage at all, even OpenGL texture creation function used is different (glCompressedTexImage2D vs glTexImage2D). You could use Desired := ifR8G8B8; to the same effect as you use A8Gray8.
Based on your asm output it looks like crash has something to do with ATI OpenGL driver (atioglxx).

[Schmackbolzen]

Right and that's why I did this change ;) The odd thing I noticed at first is, that as soon as I don't use

Code Select Expand

vec4 IBump   = texture2D(normalMap, gl_TexCoord[0].st);
in the glsl shader the crash does not occur, so I started experimenting (it's no important project) and my first conclusion was either driver error or format error, since with changing the image to normal grayscale (uncompressed) it did work. But now since it does also work with ATI2N using a LCL application this whole thing does not make much sense to me, at least not yet...

Btw. ATI1N does not make any trouble, I use it for parallax mapping and there never was any trouble when I only bound the ATI1N heightmap texture without binding the ATI2N texture in the shader. This was what let me to believe maybe there is an error in the ATI2N format converter / loader (or how you want to call it) and why I decided to post here ;)

[Galfar]

Maybe try force the format to DXT too to see if the error has something to do with used texture creation function (glCompressedTexImage2D vs glTexImage2D).

Have you tried isolating FPC compiler switches as I wrote earlier?

[Schmackbolzen]

I was on it, currently I have most of it identically (included lcl etc., the compiled app is now ~15 mb :D) and the last thing I noticed was, that i did not include the unit openglcontext (from lazarus components). As soon as I remove that for my working app, it crashes (I normally use SDL for context creation, now switched to glfw for testing, but my first try was the lazarus openglcontext component and I obviously did not remove the unit from the list. So there you have it. Now comes the question, why does it not work with SDL or glfw... guess I have to analyse the initialtization code of the openglcontext unit.

[Schmackbolzen]

Update: It also works if I don't let the ImagingOpenGL unit use the dglopengl unit, but the standard gl, glext units (I do use the dglopengl unit!). Maybe at some point you are mixing calls, but this needs further research.

Edit: Which I did and this time I did NOT look in the delphigl forum (where it states, that version 2.1 is the newest), but in the wiki. And actually there IS a newer version..... No comment, now it runs well :D

[Schmackbolzen]

Sry, was to fast (and tired). It did not compile because of an error and I started and old version (with the gl and glext units). I better go to bed now and try to look into this with a rested mind ;)

[Schmackbolzen]

Alright I tracked it down to

Code Select Expand

{ according to bug 7570, this is necessary on all x86 platforms,
    maybe we've to fix the sse control word as well }
  { Yes, at least for darwin/x86_64 (JM) }
  {$if defined(cpui386) or defined(cpux86_64)}
   SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,exOverflow, exUnderflow, exPrecision]);
  {$endif}
in the initialization part of gl.pas. You'll also need

Code Select Expand

{$if defined(cpui386) or defined(cpux86_64)}
uses
  math;
{$endif}
after the implementation keyword.

I have no clue (yet), what kind of bug they are talking about and what they change there (looks like disabling some exceptions?), but after I add this change to your ImagingOpenGL unit, everything works as normal. Maybe I should report this to the dglopengl team?

[Galfar]

Good work tracking this down.

Definitelly report it to DGL team, there's more info in description of that 7570 bug http://bugs.freepascal.org/view.php?id=7570.