OpenGL 3+ RenderSystem

[scrawl]

Still have not tried this yet, due to the aforementioned error.

Just found this analysis of Ogre's GL2 renderer (which looks pretty bad): https://github.com/realXtend/naali/issues/440
I guess that most of the issues would hopefully be addressed by state caching (as in the roadmap) and the new GL3 renderer. It might be worth to use gDebugger, it alerts you of legacy functions and redundant calls.

[sparkprime]

My batch count is currently about 4 or 5 times what it should be, and has been getting worse the more I have been using shaders and the like. I haven't properly investigated it yet, but I'm pretty sure it's worse in GL than D3D. I'm expecting to have to do significant work within Ogre to resolve this, and don't plan to do that for a few months. I may even do it on D3D9-only at first since that's where most of the users are. But i'm interested in discussing the subject generally.

[sparkprime]

My shaders use dozens of uniforms, most of the values of which do not change from frame to frame, so uniform buffers seem like a good thing to explore.

[masterfalcon]

Definitely. That's a high priority item.

The only thing that I need to figure out is exactly when we should use them. Only for shared parameter blocks?

[sparkprime]

What are shared parameter blocks exactly? These are the GpuProgramParameters objects that are reference counted and shared between GPU programs?

I believe I have one per material so I am probably not sharing those very much (no more than material sharing either). But if that means repeated renders (across frames) with no changes to materials run a lot faster, that is a big step forwards.

What about splitting off the scene stuff into a separate block of uniforms? It could be possible to provide a single block with all of the per-frame stuff in it, like sun colour, shadow camera settings, and whatever. This stuff does change for me every frame (there is a day/night cycle) but it could be uploaded and then shared by all the draw calls in that frame. Some room for custom parameters within the scene uniforms would be good too. Maybe this should be per render target actually?

Also splitting off custom movable object parameters into their own block (per movable object) -- is that a good idea?

[masterfalcon]

Yeah that's right. The main purpose of them now is to make groups of parameters easily shared between Ogre program definitions. But it could be used as a hint to create a UBO, which would still be useful for a single material.

I don't think we should have a large built in shared parameter block. Not all of them would be necessary for everyone and it would result extra uniforms being updated and larger uniform buffers.

[PhilipLB]

OpenGL 4.3 just got released and adds Compute Shader. So they are available for DX11 and GL4.3 now and it's imaginable to have them in Ogre, too?
http://www.opengl.org/documentation/current_version/

[sparkprime]

I don't think we should have a large built in shared parameter block. Not all of them would be necessary for everyone and it would result extra uniforms being updated and larger uniform buffers.

How large would it be though? About 20 floats or something? And it'd updated once per frame. I dunno about GL but in CUDA the constant buffer on a nvidia card is about 64k (8k of it being cached or something like that) so I don't think we'd have a space problem. It'd probably be worse to try and have custom buffers for every material anyway (with only the uniforms they needed). That would be duplication, surely?

[sparkprime]

Related to this sort of thing -- At the moment I'm binding 5 textures for every draw --

* shadow texture 1
* shadow texture 2
* shadow texture 3
* PCF noise texture
* stipple texture (for fade)

These ought to be candidates for some sort of 'scene' state too, right? Keep these guys bound in the first few slots while changing everything else from draw to draw?


disclaimer: Actually since I started using deferred shading only forward shaded objects are like this, but there is still that stipple guy for everything else too.

[sparkprime]

Or is it in fact better to have the first 5 textures in your materials be the same, so that there is no actual state change (even if Ogre issues one to the render system)?

[Shtuka]

The most recent update is from 23/07/2012. What is missing? Can I somehow help?

[masterfalcon]

I've got a whole lot of work in progress. Some of which I could commit. Just been busy.

[TheSHEEEP]

OpenGL 4.3 just got released and adds Compute Shader. So they are available for DX11 and GL4.3 now and it's imaginable to have them in Ogre, too?
http://www.opengl.org/documentation/current_version/

I'd be interested in this as well.
Compute Shaders sound very useful, indeed. And as I'm not a friend of DirectX (or rather programming in different languages for different platforms when OpenGL works everywhere), it would be great to have access to those in Ogre.

Then again, I guess you could simply use Compute Shaders yourself without Ogre offering any interface for it (as long as Ogre itself does use OpenGL, of course).
From the examples I've seen so far - this one is DirectX, but OpenGL can't be that different here - that shouldn't pose that much of a problem.

[sparkprime]

Are they much different to OpenCL / CUDA?

[TheSHEEEP]

I've read somewhere that they are indeed very different to OpenCL.

I haven't used them, of course, but what I read was that OpenCL was designed to be primarily for that - doing all sorts of calculations on the GPU. It has an extra interface, which seems to be very different from the normal shader interface, etc.
But focusing on OpenCL/CUDA is of very limited use to 95% of projects, I'd say. Too much hassle for not enough gain. Also, how much % of the current hardware does support that at all?
Most OpenGL projects may want to use it "just a bit" at some points. For those projects, going the full OpenCL/CUDA way would be madness, so Compute Shaders were introduced to OpenGL for those developers.

At least, this is how I see it.

And in any case, it will be some time anyway before 4.3 will be spread enough to be implemented and then used.
Like using DirectX 10 features was rather pointless in the beginning as almost no client PC would be able to use them.

So I'd say, don't mind that for now and focus on the 3.0+ support, as I think you're doing anyway, without me playing Captain Obvious

[Kojack]

The OpenGL compute shader is not designed to replace APIs like OpenCL, which has the advantage of being able to run on CPUs, GPUs and other processors.

“OpenCL is designed for large, standalone compute applications,” explains Trevett. “OpenGL shaders are designed for smaller amounts of compute that you can express in a GLSL shader but want to interoperate with the rest of the GL pipeline. Quite different use cases.”

There have also been some developments to OpenCL that make it easier to develop OpenCL applications using a new Open Source API for OpenCL Prototyping called CLU. According to Trevett, CLU should help reduce the time it takes programmers to develop their first OpenCL application from two days to an hour.

(Neil Trevett is the president of the Khronos Group)
http://develop3d.com/blog/2012/08/siggr ... n-graphics

[holocronweaver]

Just to be clear, tessellation shaders from OpenGL 4 are being implemented in this render system update, correct?
This is the #1 feature that is preventing me from using OGRE in my game engine. I rely heavily upon tessellation shaders for procedural terrain and meshes. The performance boost and ease of maintenance have saved me weeks worth of development time.
If there is anything I can do to help implement tessellation shaders and get them into the 1.9 repository, let me know. Coding, testing, whatever you like, I am on it.

[masterfalcon]

They will be. I haven't yet but I've been planning on doing so very soon. Though I'll be testing it on linux. Someone will need to do the Win32 support.

[holocronweaver]

So long as it does not involve conversion from OpenGL to D3D, I could try my hand at the Win32 port. Is the Linux implementation far enough along to begin porting? If not, do you possibly have an ETA on when it will? Cross-platform compilation is important to my current project so I have a strong interest in seeing this through.

[masterfalcon]

Well basically I just need to update the windowing to create a the right context. Also, and I cannot reiterate this enough:

The GL3+ rendersystem will not be final for 1.9, but will be included as experimental or alpha. It's functional, but not finished. There will be bugs and possibly performance regressions. But it's a very large step forward and those issues will be resolved with time.

[TheSHEEEP]

Would it make sense to have rather structured plan (probably Excel or Google Drive spreadsheet) explaining what remains to be done for GL3+?
This way, it would be easier to split into single tasks and with single tasks defined, other people might be able help out.

[masterfalcon]

That will also come soon. I have a list locally that I've been working off of.

[Wolfmanfx]

Jira!

[spacegaier]

Jira!

+1

[TheSHEEEP]

+2