Depth sharing Design

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.

Re: Depth sharing Design

Postby dark_sylinc » Mon Jan 18, 2010 2:17 am

I've update the patch (same link, now needs SVN rev 9725)

Now compositor scripts can specify which pool Id they use.
Example:
Code: Select all
texture rt0 target_width target_height PF_R8G8B8A8 depth_pool 2

Default value is "1" (DepthBuffer::POOL_DEFAULT) "0" disables ZBuffer for this RTT.

I've been thinking, this can also improve some of the existing compositors, since there are a lot of post-processing compositors which don't actually need a depth buffer at all. This could mean saving GPU memory (specially in OpenGL, Direct3D usually doesn't waste because normally the RTT resolution is lower than the backbuffer's).

Due to sinbad's request, the patch is now on sourceforge.net
Last edited by dark_sylinc on Sun Feb 14, 2010 5:58 am, edited 1 time in total.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Noman » Tue Jan 19, 2010 1:02 pm

Great stuff!

I have not had the time to review the patch up close, but I noticed that the manual did not get updated. Adding new directives to the script comes along with updating the manual.
In this case, it would be in Docs\src\CompositorScript.inc.

Besides that, is this patch finished as far as you're concerned? If so, we can start setting up tests for it before we merge it into trunk (not 1.7 of course)...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: Depth sharing Design

Postby dark_sylinc » Thu Jan 21, 2010 2:50 am

I would like to finish (start) the documentation (like you said, Docs\src\CompositorScript.inc is one of them) and add DirectX 10 support.
I've tested linux (not thoroughly) and seems to work fine. The main reason seems because the only difference is in OGL's handling of the main backbuffer, which doesn't allow sharing it's depth buffer anyway and that's why it doesn't show problems.

Anyway, yep, I think it's ready (or almost) to start being tested by others and see how it performs.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Sairon » Sat Jan 23, 2010 5:44 pm

Downloaded and applied to latest svn trunk. It doesn't seem that it's possible to control the depth buffer in the way specified in the original post. Skimming the patch it seems like a lot of it, if not all, is present but not exposed to compositor scripts yet, is this correct? depth_pool attribute however seems to be exposed. Using depth_pool I've been able to make my off screen MRT & BB share depth buffer, however I can't seem to control the clearing of it. Even without a clear pass in my compositor it seems intent on clearing it between passes. Is it perhaps something I've missed?
Sairon
Halfling
 
Posts: 94
Kudos: 0
Joined: 20 Apr 2007

Re: Depth sharing Design

Postby dark_sylinc » Sat Jan 23, 2010 7:43 pm

Sairon wrote:Skimming the patch it seems like a lot of it, if not all, is present but not exposed to compositor scripts yet, is this correct? depth_pool attribute however seems to be exposed.

No. If you read the whole thread (can't blame you for not doing so ;) ) you'll see the only option that was left was depth_pool; the other options were abandoned because it was too low level and overly complicated.

Sairon wrote: however I can't seem to control the clearing of it. Even without a clear pass in my compositor it seems intent on clearing it between passes. Is it perhaps something I've missed?

Ewww, I've not tested clear passes. Probably you can't control it because the code is just using whatever depth buffer left over from last render pass. I'll take a look.

Thanks for trying it out!
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby dark_sylinc » Sat Jan 23, 2010 7:59 pm

Ok I've just tried different clear passes and they all worked as expected.
What's what you're doing? What is the expected result or you intend to do; and what's actually happening?

Edit: Are you using D3D9 or OGL?

Just as a remainder, it's very common to make a couple mistakes when writing a clear pass in the compositor, so here goes an example of a well-written clear pass. If yours doesn't look like this one, it won't work:
Code: Select all
target rtt0
{
   input none

   pass clear
   {
      clear
      {
         //Clear Colour & depth explicitly
         buffers colour depth
         colour_value 0 0 0 0
         depth_value 1.0
      }
   }

   //This pass is optional, you don't need it to clear an RTT or it's depthbuffer
            pass render_scene
            {
            }
}
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Sairon » Sat Jan 23, 2010 9:15 pm

I've taken a deeper look, here are my findings so far. If I do an explicit clear pass, as you describe, then I get a controlled clear, working just as expected. But there's also an implicit clear which I just can't seem to avoid which happens as soon as the render target is switched. I presume this doesn't happen for you so I'll see if I can find the cause if I look deeper :)
Sairon
Halfling
 
Posts: 94
Kudos: 0
Joined: 20 Apr 2007

Re: Depth sharing Design

Postby Sairon » Sat Jan 23, 2010 9:26 pm

I seem to have found the issue, I had clearEveryFrame to true on the viewport. I think it's a bit misleading because it doesn't clear every frame, it clears on every render.
Sairon
Halfling
 
Posts: 94
Kudos: 0
Joined: 20 Apr 2007

Re: Depth sharing Design

Postby dark_sylinc » Sun Feb 14, 2010 6:01 am

I've updated the patch in both SF.net and the mirror.
Now there's documentation in the patch.
It affects the Compositor and texture shadows docs.
SVN 9725 is needed

I'm now aiming towards DX10 and getting familiar with the code. I have a Vista machine without D3D10 card and a machine w/ a D3D10 card without Vista. grrr...

Judging from how it looks, it seems each RT in D3D10 is getting it's own depth buffer. No sharing at all.

Edit:
Not just that, I can't also find where the created depth buffers are being released.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Noman » Sun Feb 14, 2010 11:51 pm

Not a DX expert, but we can wait with DX10 support until this one is in trunk, as long as we make sure to just set the RenderSystemCapabilities flags accordingly.
I'll hopefull be able to test the patch on my machine. If that works, we'll try to get someone with a multi-monitor environment to test it there as well, and if all goes well we'll hopefully merge this into trunk.

Didn't have a close look at the last patch yet, but great job nonetheless!
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: Depth sharing Design

Postby dark_sylinc » Mon Feb 15, 2010 2:44 am

Just got my hands in a win7 machine with DX10 hardware!......... no one mentioned the plugin was SO unstable.

70% of the samples don't work (usually it's because they're not prepared to handle that ps_3_0 and lower profiles don't exist). Even the isosurf example refused to work.
And when I tried to go fullscreen at my monitor's native resolution, the resolution was ok but the screen was stretched to 3/4 of the screen!
Not to mention other crashes... (i.e. when going from fullscreen)

This makes me reconsider my D3D10 efforts and gonna follow your advice.
I've been working w/ patched Ogre for a while now (D3D9 & OGL) and it's been working nicely :)

Indeed we need someone w/ multi monitor setup. Unfortunately I thought I had another DVI-VGA adapter, but it was actually DVI-HDMI; so I can't test it.

As for setting the right RenderSystemCapabilities, I've been thinking that we should state that if none of the new flags are set, this depth pool system is not usable. Some RenderSystem (i.e. D3D10, D3D11, OGL ES) may not have yet implemented at all depth sharing with pool IDs, or the API just doesn't allow depth sharing (I'm thinking of possibly handhelds here).
When that happens, assumptions about depth buffer sharing can't be made.
What do you think? Or should we add a new flag to indicated this?

Please start testing this patch, so we start seeing in trunk

Cheers
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby dark_sylinc » Mon Feb 15, 2010 7:31 am

Yippiee!! Direct3D10 support in ONE NIGHT! How about that! (though, it's very laaaate....)
I'm certainly more productive at night.

I'm using a separate patch for D3D10 with important bug fixes that should be checked in ASAP:

* Going to fullscreen could cause to switch to a different resolution due to wrong refresh rate parameter. Symptoms varied from wrong resolutions, stretched images, to crashes.
* FSAA was not working at all. The code was all screwed. Fixed.
* Depth buffers weren't being released, causing occasional crashes when switching from fullscreen to windowed mode.
* Depth buffers weren't being shared at all (very different behavior from D3D9 & OGL) Fixed with the new system.

Edit:
It's ready for checkin now 8)

Edit 2:
For those render systems that aren't using this new system yet (OGL ES, D3D11), they won't compile because _createDepthBufferFor is pure virtual. Just overload it and return null to workaround this problem.

Edit 3:
Added D3D11 support
Last edited by dark_sylinc on Tue Feb 16, 2010 4:05 am, edited 1 time in total.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby lf3thn4d » Mon Feb 15, 2010 8:19 am

Awesomeness! Can't wait to have this in trunk. I need this for doing light pre-pass rendering with additional screen space refraction. :)
User avatar
lf3thn4d
Orc
 
Posts: 478
Kudos: 12
Joined: 10 Apr 2006

Re: Depth sharing Design

Postby Noman » Mon Feb 15, 2010 9:52 am

Patch compiles fine, related demos (compositor / deferred shading) also run well in both D3D/OGL. Should any other samples behave differently? (shadows?)
I didn't have a deep down look at the code itself yet, I hope to get to that soon.
I currently can't test in DX10, probably won't be able to in the next 2 weeks. Also, if some of the fixes you made to DX10 are unrelated to the patch, it might be worth to separate them into a different patch so we can apply that one to 1.7 as well.

Two things :
A) Did you write a playpen test for stressing the system (or maybe an example of using the actual depth buffer from one viewport in another) ? Could be useful to see that it works as well. I still don't feel that checking the compositor/deferred shading demos is sufficient, because they don't use the entire toolset that you added here. Correct me if I'm wrong?
B) We really need to get a multi-monitor testing setup.

Hopefully I'll be able to take some time and look at the code soon and we'll take it from there...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: Depth sharing Design

Postby dark_sylinc » Mon Feb 15, 2010 5:25 pm

Noman wrote:Patch compiles fine, related demos (compositor / deferred shading) also run well in both D3D/OGL. Should any other samples behave differently? (shadows?)

I designed the code so that, as long as the configs aren't changed, the default values behave pretty much the same it used to be. I haven't seen any sample behaving improperly yet.

Noman wrote:Also, if some of the fixes you made to DX10 are unrelated to the patch, it might be worth to separate them into a different patch so we can apply that one to 1.7 as well.

OK, I'll try to see what I can do about that.
I didn't bother splitting it up because many of the changes altered depth buffers as well.

Noman wrote:Two things :
A) Did you write a playpen test for stressing the system (or maybe an example of using the actual depth buffer from one viewport in another) ? Could be useful to see that it works as well. I still don't feel that checking the compositor/deferred shading demos is sufficient, because they don't use the entire toolset that you added here. Correct me if I'm wrong?

You're right. And yes, I do have a playpen test to stress this system. I'll try to tidy it up so it can be publicly released to be tried out.
Nevertheless, compositors could start getting the benefits of the system. Many compositors (i.e. bloom, motion blur, gaussian blur, radial blur, Black & White) don't need a depth buffer at all. Setting "depth_pool 0" would save VRAM memory, as well as showing how to use the new system.

Noman wrote:B) We really need to get a multi-monitor testing setup.

Indeed.

Cheers
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby dark_sylinc » Tue Feb 16, 2010 5:04 am

dark_sylinc wrote:
Noman wrote:Two things :
A) Did you write a playpen test for stressing the system (or maybe an example of using the actual depth buffer from one viewport in another) ? Could be useful to see that it works as well. I still don't feel that checking the compositor/deferred shading demos is sufficient, because they don't use the entire toolset that you added here. Correct me if I'm wrong?

You're right. And yes, I do have a playpen test to stress this system. I'll try to tidy it up so it can be publicly released to be tried out.

I've uploaded a simple application, you Noman probably saw a similar one not long ago.
When depth buffers are shared, you should get a flickering box due to z fighting problems. There are two compositors, "WorksForEveryone" & "WorksForD3D_Not_For_OGL". The names are self-explanatory.
The application is hardcoded to load "WorksForEveryone"; I just swap the names in the compositor to quickly load the other one. If you need something more fancy, let me know.

Here's the test

I include the source & the compiled application w/ D3D10, D3D11, OGL & D3D9
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Noman » Sat Feb 20, 2010 1:16 pm

Had a closer look at the code, looks fine to me - conventions etc are all up to spec with ogre.
The implementation itself also looks good. I'm not a D3D expert, but it seems fine.

The only thing that worries me (meaning needs specific checking) besides multi screen is leakage. I know that in D3D some calls return pointers that have to be released, and I don't know how GL behaves in those areas.

Did you try running these tests using the D3D debug runtime? (I'll probably run those tests soon and see what happens).
Also, does anyone know of parallel tools for OGL? (I heard about gDebugger but have no idea what it does or how to use it)...

After these tests, I think its OK to merge this into trunk.

That being said, can anyone with a multi-screen setup test this patch?
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: Depth sharing Design

Postby dark_sylinc » Sat Feb 20, 2010 7:59 pm

Noman wrote:The only thing that worries me (meaning needs specific checking) besides multi screen is leakage. I know that in D3D some calls return pointers that have to be released, and I don't know how GL behaves in those areas.

Did you try running these tests using the D3D debug runtime? (I'll probably run those tests soon and see what happens).

For D3D9, done this, I've checked the debug runtimes, no leaks reported so far.
For your information, you can look at "RenderSystem::_cleanupDepthBuffers". It is called (or should be) to delete all depth buffers.
Depth buffers release their surface (which should be zero after that) on the destructor (in OpenGL this means glDeleteRenderbuffersEXT gets called)
Also the destructor from the base class is virtual and detachFromAllRenderTargets() is called, so there shouldn't be any pending binding on any RT that could keep the reference count higher than 0.

In D3D9/10/11, depth buffers tagged as "manual" aren't released in the destructor and have to be released later. Manual depth buffers are used to hold the depth buffers from the backbuffer's (i.e. the main Render Window). The system expects the depth buffers to be released by the routine which created the backbuffer/RenderWindow (which is what happens, see D3D9Device::releaseRenderWindowResources)

In OGL the main backbuffer can't share it's depthbuffer with FBOs, so no need to worry there.
Regarding gDebugger, it looks marvelous if it weren't that the trial versions cuts you out the good stuff. And I'm not buying a copy for an API I barely use and keeps breaking without me being at fault.

Nevertheless, I'm modifying right now _cleanupDepthBuffers to include a boolean parameter to avoid deleting manual depth buffers, this way an application can free all unused depth buffers at will if he thinks the pool has grown very big and he doesn't need them anymore. This would for advanced users.
I'll let you know when the patch is updated

The only thing I couldn't try yet and can't guarantee it's quality at all is multi monitor. I've already asked Assaf if he could give it a try, and he agreed; I didn't heard anything from him yet.

I'm hoping I can get an extra DVI-VGA adapter next monday.

Edit
Patch updated in both SF.Net & Mirror. Apply again. It's a tiny change for _cleanupDepthBuffers
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby dark_sylinc » Tue Feb 23, 2010 4:08 am

Okeey. I bought an extra DVI-VGA adapter and hooked my old 15' CRT monitor.

It performed well with a couple bugs I've fixed:
* D3D9DepthBuffer::isCompatible wasn't checking if this was the right device.
* When the window moved from one monitor to the other one, a new device is created and the old one was release, but the depth buffers still where there; accumulating forever in the pool only to be released on shutdown (also could cause crashes when restoring devices if the driver doesn't handle D3D leakages too well).

I've tried Cloned View (which isn't actually multimon), moving windows from one monitor to another; and multihead fullscreen.

So, notable changes were:
* Changes to D3D9DepthBuffer::isCompatible()
* Added D3D9RenderSystem::_cleanupDepthBuffers( Direct3DDevice9 *creator ); which is specific only to D3D9 RS, it is used to remove from the pool all depth buffers which where created by a specific device.
* D3D9Device::destroy() now calls the function above first.

[sarcasm]A big thanks to the OGRE team on documenting how to setup multiple windows with multi head D3D9 device support in 5 minutes.[/sarcasm] (seriously, not even a damn forum post. Had to debug the code to see how it worked and then trial & error. Yes, I've seen the 3 forum threads regarding the multimon patch by Nir Hasson, but they don't tell you how to set it up)
I'm not mad, just laughing of myself :lol: . Though seriously that needs documentation. It's a really cool feature private for only a few (those who have multiple monitors and know how to set it up)

I have to admit, although it was a 15' CRT monitor, it was pretty cool & handy to debug fullscreen applications while looking at the code at the same time.

All the high priority tests where made, now it's up to you to check it in to trunk.
Patches have been updated (SF.Net & mirror)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 858
Kudos: 169
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Noman » Tue Feb 23, 2010 7:22 am

Awesome!

I'll have a final look at the patch, run the tests once more and hopefully commit it by the end of the week.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: Depth sharing Design

Postby Noman » Tue Feb 23, 2010 11:15 pm

Updated patch compiled & ran fine on windows, and compiled cleanly on linux.
It is now in trunk!
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: Depth sharing Design

Postby masterfalcon » Wed Feb 24, 2010 2:42 am

Awesome work Noman! I have to admit, I haven't been following this thread but I'll look into getting this into the GLES and GLES 2 rendersystems asap!
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
 
Posts: 4264
Kudos: 129
Joined: 25 Feb 2007
Location: Bloomington, MN

Re: Depth sharing Design

Postby Noman » Wed Feb 24, 2010 7:12 am

I'm just the middle-man... It's dark_sylinc who did the real work.

Speaking of GLES/2 - I don't think they were modified. They might have some pure-virtual calls that might cause linker errors. (Can't check since I don't have a compilation environment for them).
Can you make sure that they still compile correctly?
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: Depth sharing Design

Postby magento_news » Wed Feb 24, 2010 7:50 am

Thanks a lot for sharing the code.
magento_news
Gnoblar
 
Posts: 1
Kudos: 0
Joined: 22 Feb 2010

Re: Depth sharing Design

Postby lf3thn4d » Wed Feb 24, 2010 8:00 am

Excellent! I can finally code light pre-pass rendering with ease. :D Thanks a heap dark_sylinc & noman!
User avatar
lf3thn4d
Orc
 
Posts: 478
Kudos: 12
Joined: 10 Apr 2006

PreviousNext

Return to Developer talk

Who is online

Users browsing this forum: No registered users and 2 guests