Open srmainwaring opened 3 years ago
A small nitpick that is probably not of relevance on macOS GL3 (but relevant everywhere else).
You first clear but then tell the GPU to ignore that clear:
target rt_output
{
// Clear to yellow
pass clear
{
colour_value 1 1 0 1
}
// Copy texture from rt_green
pass render_quad
{
//use_quad yes
load { all dont_care }
material Ogre/Copy/4xFP32
input 0 rt_green
}
}
This is because the 2nd pass says "dont_care", you're literally saying I don't care what was in the render target I am about to render to (which you just cleared).
A fix would be to just do:
target rt_output
{
// Copy texture from rt_green
pass render_quad
{
//use_quad yes
load
{
all clear
// Clear to yellow
clear_colour 1 1 0 1
}
material Ogre/Copy/4xFP32
input 0 rt_green
}
}
@darksylinc thanks for the fix, please excuse the mistakes. The example doesn't really need to clear to yellow but it does help trace the render when stepping through Xcode on the Metal version. Unfortunately there aren't equivalent tools for OpenGL on macOS now.
I'm happy to continue with the detailed investigation but could do with some guidance on where & what to look for. My next thoughts are to look at setting an initial texture for the GL3PlusTextureGpuRenderTarget
in the code where it is created and initialised to check if it is transitioned to resident correctly - but you may have better suggestions on how to best go about isolating the issue.
Give the simplicity of your sample, things I can think of:
GL3PlusRenderPassDescriptor::performLoadActions
params.insert( std::make_pair("gamma", "No") );
) and declare your compo local texture as PFG_RGBA8_UNORM
glTexStorage2D
is broken and we must resort to emulating it with glTexImage2D
; i.e. they're doing this internally (emulating glTexStorage2D with glTexImage2D) and they screwed upThanks for the suggestions. Analysis so far:
- Try disabling sRGB entirely (sRGB Gamma Conversion = No; or simply
params.insert( std::make_pair("gamma", "No") );
) and declare your compo local texture asPFG_RGBA8_UNORM
Tried this first with no change in the outcome.
- Clear is broken. We changed how we clear a lot in 2.2; the relevant code is in
GL3PlusRenderPassDescriptor::performLoadActions
I have not looked through the implementation yet, but modified the compositor to remove the clear pass on the local texture (and remove the dependency on clear (?)).
Changes:
local texture:target rt_green { ... }
render window: target rt_output { ... }
rt_green
to rt_output
Result: no change in outcome. This suggests that clear is not the problem.
Next step is to look at emulating glTexStorage2D
, IIRC think there's code for this in Ogre2.1 so I'll look that up.
Next step is to look at emulating glTexStorage2D, IIRC think there's code for this in Ogre2.1 so I'll look that up.
Since we're trying to determine the cause of the problem and your sample is very simple, I think simply replacing glTexStorage2D() calls with a glTexImage that always creates an RGBA8888 will do.
Btw what happens if you change the clear colour? i.e. from green to blue or red? Same result? Different? That is key.
Result for GL3+ is independent of the clear colour. Always returns the second image posted above.
Oh that's a good help!
It could mean:
GL3PlusRenderSystem::_setTexture
uniform sampler2D tex;
points to the wrong sampler unit. I doubt this is it, because this code didn't change from 2.1 to 2.2GL3PlusRenderPassDescriptor::updateColourFbo
handles thisGL3PlusRenderPassDescriptor::performLoadActions
does this when it calls glBindFramebuffer and glDrawBuffer. GL3PlusRenderPassDescriptor::performStoreActions
unbinds the FBO.I just realized that if shadow mapping is working, then FBO and RenderToTexture stuff is working fine. This is heck a lot confusing.
Edit: I assume you're working with MSAA disabled, at least the problem is isolated. MSAA adds a lot of uncertainty I'd rather not deal right now.
Btw this is stupid, but I didn't ask for Ogre.log. Perhaps there's relevant info there. Could you upload it? Thanks
This from a more recent version than pushed to github (Ogre/ColourGreen/4xFP32_ps_GLSL is Ogre/Copy/4xFP32_ps_GLSL with a hardcoded fragment).
AFAIK MSAA is disabled (I am using the default config settings aside from screen size).
Edit: I have observed some odd behaviour in the samples that are rendering which suggest not all is well. The PbsMaterials sample will not render properly if the block that sets the environment cube maps on the translucent spheres is removed. The Forward3D sample will run but has the light tiles all misaligned (they don't initially show, but if you increase the number of lights they appear and stay visible, but misaligned, when the number of lights is decreased again).
This could be a major facepalm:
What happens if you do:
// out vec4 fragColour; // Comment it out
#define gl_FragColor fragColour
Compile error:
GLSL compile log: Ogre/Copy/4xFP32_ps_GLSL
ERROR: 0:28: Use of undeclared identifier 'fragColour'
ERROR: 0:33: Use of undeclared identifier 'fragColour'
ERROR: 0:41: Use of undeclared identifier 'fragColour'
ERROR: 0:46: Use of undeclared identifier 'fragColour'
WARNING: GraphicsSystem::deinitialize() not called!!!
An exception has occured: OGRE EXCEPTION(3:RenderingAPIException): Fragment Program Ogre/Copy/4xFP32_ps_GLSL failed to compile. See compile log above for details. in GLSLShader::compile at /Volumes/MacPro2_DV1/Code/ogre/ogre-next2.2/RenderSystems/GL3Plus/src/GLSL/OgreGLSLShader.cpp (line 314)
Program ended with exit code: 255
(this on my modified version returning the channels in quadrants - so the 4x appearance of fragColour)
Sorry I messed up, it should've been:
#define fragColour gl_FragColor
Still compile error:
GLSL compile log: Ogre/Copy/4xFP32_ps_GLSL
ERROR: 0:28: Use of undeclared identifier 'gl_FragColor'
ERROR: 0:33: Use of undeclared identifier 'gl_FragColor'
ERROR: 0:41: Use of undeclared identifier 'gl_FragColor'
ERROR: 0:46: Use of undeclared identifier 'gl_FragColor'
WARNING: GraphicsSystem::deinitialize() not called!!!
An exception has occured: OGRE EXCEPTION(3:RenderingAPIException): Fragment Program Ogre/Copy/4xFP32_ps_GLSL failed to compile. See compile log above for details. in GLSLShader::compile at /Volumes/MacPro2_DV1/Code/ogre/ogre-next2.2/RenderSystems/GL3Plus/src/GLSL/OgreGLSLShader.cpp (line 314)
Program ended with exit code: 255
Wtf? Ok then try:
layout(location = 0, index = 0) out vec4 fragColour;
Compiling correctly. Runs with same result as above.
3. This would be weird but perhaps macOS'
glTexStorage2D
is broken and we must resort to emulating it withglTexImage2D
; i.e. they're doing this internally (emulating glTexStorage2D with glTexImage2D) and they screwed up
I don't think there is an issue with glTexStorage2D
: Ogre2.1 is using glTexStorage2D
(with a fallback to glTexImage2D
) and on my mac the GL_ARB_texture_storage
branch is executed and working correctly.
Edit
Ok - I think the problem is that the colour attachment on the FBO is never set on macOS. I've put a break on every glFramebuffer....
call in GL3PlusRenderPassDescriptor
and AFAICT none that set colour attachments are being hit.
In GL3PlusRenderPassDescriptor::updateColourFbo
the loop over mNumColourEntries
that attaches the colour entries skips the calls to either glFramebufferRenderbuffer
or glFramebufferTexture
because bSupportsTIR == false
(which takes out both the if and else-if branches).
Still issues to resolve, but have something rendering now (if not the main scene). I have just set bSupportsTIR = true
in GL3PlusRenderPassDescriptor::updateColourFbo
, commented out the block setting various framebuffer params and tried running the Postprocessing sample. This with the Old TV effect on:
and FBO errors which are not unexpected given the hack above:
OpenGL error 0x0502 GL_INVALID_OPERATION in void Ogre::GL3PlusRenderPassDescriptor::updateColourFbo(Ogre::uint8) at line 282 for glFramebufferTextureLayer
Now need to set about understanding what a proper fix involves.
System Information
Detailled description
When using a compositor that uses a local texture (e.g.
Postprocessing.compositor
) on macOS with the GL3+ render system; the local textures do not seem to be working properly.To trace the problem I created a simple compositor example available here: https://github.com/srmainwaring/ogre-next/tree/feature/v2-2-macos-sample-compositor.
The compositor clears a local texture to a colour (green for the example below) and the render window to yellow, then a render_quad pass is used to copy the local texture to the render window.
I use a modified version of the
Copyback_4xFP32_ps.glsl
shader to display the channels in quadrants (with a similar version for metal):Metal
The metal version works as expected with the green quadrant visible and the alpha quadrant white.
GL3+
The GL3+ version does not show green. The blue quadrant is visible and the alpha channel is not white.
Setting the pixel shader to display the texture coordinates confirms that the GLSL Quad vertex shader is working correctly, which points to a possible issue with the
GL3PlusTextureGpuRenderTarget
on macOS.There doesn't seem to be anything in the log to indicate an OpenGL compilation error (this with
ENABLE_GL_CHECK 1
inOgreGL3PlusPrerequisites.h
).Ogre.log