MRT crashes GPU drivers?

I’m running an AMD R9-280X with the Catalyst 14.11 beta drivers (though the problem also existed on WHQL 14.9). I have a GBuffer with 4 color maps added to it (I know, horrible idea. I’m just doing it for the fun of it). When I only write to the first two, there’s no problem. However, when I write to gl_FragData[2] or [3], my screen cuts to black and the GPU drivers crash. Here’s the code for creating it:


        gBuffer = new FrameBuffer(screenWidth, screenHeight, 1);
        normals = new Texture2D(screenWidth, screenHeight, Format.RGBA8);
        diffuse = new Texture2D(screenWidth, screenHeight, Format.RGBA8);
        tDiffuse = new Texture2D(screenWidth, screenHeight, Format.RGBA8);
        tNormals = new Texture2D(screenWidth, screenHeight, Format.RGBA8);
        depth = new Texture2D(screenWidth, screenHeight, Format.Depth);
        gBuffer.setDepthTexture(depth);
        gBuffer.addColorTexture(diffuse);
        gBuffer.addColorTexture(normals);
        gBuffer.addColorTexture(tDiffuse);
        gBuffer.addColorTexture(tNormals);
        gBuffer.setMultiTarget(true);

Is it just that GLSL can’t support more than 2 writes? writing to just diffuse and normals is fine, but writing to tDiffuse and tNormals is not. Also it doesn’t make a difference whether I write to the first two or not, if I write to [2] or [3] it crashes regardless. Is there any other information that should be provided to help diagnose this? Thanks in advance.

EDIT: It might be worth noting that with those two added to the GBuffer, it ONLY crashes when I actually write to them. If I don’t write to them in the shader it runs fine, but as soon as I call to write to them it crashes instantly.

Crashes the operating system? Crashes the application with a heapdump? Or crashes the application with an error?

The first two are driver bugs. The last one gave you an error that you haven’t shown us.

It crashes the GPU drivers, as I said. The application doesn’t get a chance to crash if that’s part of the problem because the GPU drivers crash first. When I write to those textures, my screen flickers, the app is frozen and black and I get a dialog telling me the AMD drivers crashed and recovered. I suspect it’s a drivers problem but I’m not certain and figured I would ask to make sure it’s not some limit of MRT or something.

Well, by definition it’s a driver bug since there shouldn’t be anything you can send to a driver to make it crash. AMD’s (and intel’s) drivers seem to still be pretty easy to provoke into a crash.

Now, that doesn’t mean that there isn’t also some limitation on what you are trying to do… but the driver shouldn’t crash just from doing it. (*)

    • the caveat being the assumption that the buffers have actually been provided to the GPU correctly. An app or a JME bug could be indicated but given that two of them work it seems less likely.

@pspeed AMD drivers are definitely much less stable than those of Nvidia. Can’t complain though, I got a $300 card for <$150 so I’m happy with it. I just did a little test and swapped the textures around. It doesn’t matter what textures are in which spot, if I write to the 2nd or 3rd textures it crashes. Hmmmm…I guess I’ll have to devise a better way to render translucent objects. This was mostly just a random thing anyway to see if it was even viable as a way to render translucency but I didn’t even get that far.

Does the example TestMultipleRenderTarget work?

@Momoko_Fan Interestingly, it launches without fail, but nothing comes up on the screen. Seems like AMD drivers are really hit and miss with MRT.

There is a bug into TestMultupleRenderTarget 3.0 (black screen iirc), try : the one from github : jmonkeyengine/TestMultiRenderTarget.java at master · jMonkeyEngine/jmonkeyengine · GitHub (copy/paste into your existing file).

May be no impact, on my MRT, I call gBuffer.setMultiTarget(true); before adding Texture.

Brendan, I’m also working on MRT (deferred), I’ll be glad, if you can test it on you AMD. If you’re ok, do you prefere a packaged version with jre (8.0) for windows, without jre or the source (gradle project) ?

@david.bernard.31

That would be cool, I’d prefer it packaged but it would be cool to check out the source if you’re alright with that. I’ll try switching it around and see if I get the same errors. It’s strange that it only seems to be for those two textures, which are the same format and size as the other two and are even created at the same time and used on similar materials. I don’t see how anything could go wrong outside of a driver problem.

How far along is your deferred rendering? I’ve been working for a few months on mine and I have it pretty much finished at a point that I can accept. It’s got a pretty extensive material customization system, basic alpha support, shadows (including PCF Poisson and basic dithering) and some other useful effects. I’m able to run around 1000 point lights pretty smoothly on the 280X. Next on my list of things to attempt and probably fail are procedural foliage, procedural city layouts, and procedural building layouts. Hurray for pseudorandom-ness!

Thanks, I’ll prepare native package for linux/windows for end of the week.
I start a topic about mine : http://hub.jmonkeyengine.org/forum/topic/yet-another-deferred-shading/ , it’s less advanced than yours. I didn’t test it againts lot of points of lights (not my main goal). Any advice are welcome.

About your issue, do you have a crash if you create and attach texture, but not do not try to write into it, or when to try to write ?
May not related, do you use GLSL <120 (gl_DataFrag or something like out vec4 out_FragData[ 3 ]:wink: ?