Shader Model 5.0 support in Ogre 1.12

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Post Reply
mgiordano
Gnoblar
Posts: 11
Joined: Tue Jan 10, 2012 8:49 pm
x 2

Shader Model 5.0 support in Ogre 1.12

Post by mgiordano »

Operating System: Windows 10
Render system: DirectX 11
Ogre version 1.12.1
Traditional material system (not HLMS)

It appears that there is not full support for standard shader model 5.0 in the directX 11 render system. Specifically, it looks like constant buffers are not supported. Is that correct? What modifications need to be made to the hlsl syntax in shader model 5.0 in order for it to work correctly with Ogre 1.12?

When I write a custom shader that uses constant buffers, Ogre fails to populate the constant buffers with data. Looking in RenderDoc it shows that the constant buffers were successfully compiled in the shader and recognized, however none of the data is being populated by Ogre. See the image.
Image

I'm interested in using the full capabilities of shader model 5.0 with shaders that I have written myself. What are the best practices for doing this in Ogre 1.12?

paroj
OGRE Team Member
OGRE Team Member
Posts: 1117
Joined: Sun Mar 30, 2014 2:51 pm
x 400
Contact:

Re: Shader Model 5.0 support in Ogre 1.12

Post by paroj »

Constant buffers are discovered here:
https://github.com/OGRECave/ogre/blob/8 ... m.cpp#L567

You could take a look whether something is wrong there regarding multi constant buffers.

mgiordano
Gnoblar
Posts: 11
Joined: Tue Jan 10, 2012 8:49 pm
x 2

Re: Shader Model 5.0 support in Ogre 1.12

Post by mgiordano »

Hi paroj,

It looks like everything in the function you referenced understands and handles multiple constant buffers correctly. The shader compiling and creation of data structures in Ogre based on multiple constant buffers all seems to be working, which is why I am able to see the named buffers in RenderDoc.

The issue occurs at the final stage before draw when the constant buffers are bound to the render pipeline. The current code will only ever attach a single constant buffer. It also hard-codes the location of this buffer to index/start slot 0, as can be seen in the following code:

Code: Select all

mDevice.GetImmediateContext()->PSSetConstantBuffers( 0, 1, pBuffers );
Here is the full function:
https://github.com/OGRECave/ogre/blob/m ... .cpp#L2927

There even seems to be a function ready to go for returning multiple constant buffers for binding (getConstantBuffers), but this function is never called anywhere in the codebase, only the singular one is used. See the following functions:

Code: Select all

        ID3D11Buffer* getConstantBuffer(GpuProgramParametersSharedPtr params, uint16 variabilityMask);

        void getConstantBuffers(ID3D11Buffer** buffers, unsigned int& numBuffers,
                                ID3D11ClassInstance** classes, unsigned int& numInstances,
                                GpuProgramParametersSharedPtr params, uint16 variabilityMask);
It looks like all the support for multiple constant buffers is there EXCEPT for the binding stage. I would love it if this last mile would be completed in Ogre 1.12. Any chance this is on the road-map? If not, what is the best practice for using constant buffers in Ogre 1.12?

Thanks.

paroj
OGRE Team Member
OGRE Team Member
Posts: 1117
Joined: Sun Mar 30, 2014 2:51 pm
x 400
Contact:

Re: Shader Model 5.0 support in Ogre 1.12

Post by paroj »

Thanks for investigating. As you already looked into this and also have a test-case, ideally you would make the necessary changes and create a pull-request here:
https://github.com/OGRECave/ogre/pulls

you could also take some ideas from the according change in 2.1:
https://github.com/OGRECave/ogre-next/c ... af2b484d5e

paroj
OGRE Team Member
OGRE Team Member
Posts: 1117
Joined: Sun Mar 30, 2014 2:51 pm
x 400
Contact:

Re: Shader Model 5.0 support in Ogre 1.12

Post by paroj »

for reference: the respective change has landed for GL3Plus. The additional cbuffers are attached to shared_params of same name via the HardwareUniformBuffer API

Post Reply