Ogre Forums

Today I finished merging Eugene's works , cherlix has also finished the testing module for multi-window support and added to the branch . Tomorrow morning I will test everything possible and make debugging if necessary, will also post some screenshots of the results.

Good work!

Sorry for the late, Robert. I have sent a mail to you, and I attach the screen shot here. I took it from two different resolution screens. I created two render windows, rendered them on different screen, one run in full screen mode, and the other run window mode. It works fine.

I have resolved the conflicting errors between my work and eugene's. The next thing to deal with is the multi-device support , which will be done as it was discussed in this forum thread previously.

ok.

I merged the code with Ogre1.9, because I tried to find solution for an unexpected error.
First error: in OgreD3D11DepthBuffer::isCompatible line 78. renderTarget->getCustomAttribute( "DDBACKBUFFER", &pBack ); gives and Ogre exception because it says it has no such an attribute, until merging my work with Eugene's it was working fine, because getCustomAttribute( "DDBACKBUFFER", &pBack ) arrived to OgreD3D11Texture and not to OgreD3D11RenderWindow (as it is now.).

Second error: if I comment out those lines from isCompatible (from line 61 to line 90, as it is now in the repo) I get an other error:
0x561ac948 in SampleBrowser_d.exe: 0xC0000005: Access violation reading location 0xcccccc4c on OgreD3D11RenderSystem::setRenderTargetViews, line 1933.

I would need some advice how to resolve this error.

How can I recreate the issue?
Does it recreate with the code in your repo?

Yes, I cannot even open Sample Browser because of this error. It happens when initializing the Sample Browser window for D3D11 RenderSystem in window mode.

I fixed it for us and committed to the project repo, you can continue with the next issues.

Thanks Assaf , I would have never tought about that line to cause the error. I have also resolved the other error, small bugfix on the number of surfaces created from faces and mipmaps OgreD3D11Texture::_createSurfaceList(). Now everything is working again .

Now I can work on the multi-device support. Tonight I will commit the first part of the work.

good work.

I and cherlix was working on bug fixes this week and made some adjustments to make some samples compatible with DirectX 11 Render System. There is some more debugging to be done, but as the major errors are corrected I can give more focus on the multi-device support (the interface is almost done.)

Some samples are not working because of the profile in most of RTSS's shaders supports vs_3_0, but dx11's cap contains vs_4_0, vs_4_1, and vs_5_0. So we will get the error message of not supporting shader model 3.0., but this will be resolved after the last part of GSoC programme with RTSS support and dynamic linkage .

Just wanted to drop a line here that I've added some GPU profiling code to the 1.8 repo, which will find it's way into 1.9 at some point. But I fear that it may break the DX11 build. As far as I understand you may just need to include some DX9 header. But hopefully one of you guys can figure it out.

Today I was working on the multi-device support, also made some debugging on the current render system, and corrected some of the files on the bitbucket repo. Tomorrow morning I will push my code to the repo, and also update the wiki page of this project as it is a little bit out-dated.
After I finish the multi-device support I will give a look into your changes, masterfalcon, and make the necessary changes to the DirectX 11 Render System.

Can you explain more what you are doing on the multi-device support? Also - how will you test the code?

In the first part I am copying the multi-device support from the Directx 9 Render System and change all the necessary things, it is more like rewriting everything as there are a lot of conflicts between DirectX 9 and DirectX 11. I am writing all the code keeping in mind the ideas Assaf Raman and Mattan Frust have explained in this thread.
The interface will look like the one from the DirectX 9 Render System.

About testing the code, I do not know yet how I will proceed with it. I have a laptop with 2 videocards (each compatible with DirectX 11) and a HD TV which I can connect to the laptop with HDMI cable. So I will try to run Ogre Samples through these devices (connected). I hope this is correct.

If anyone has a better idea please share it .

Two video cards are the way to go.

I have continued the work on the multi-device support. At first I thought it would be easier, but there is a lot of code to write and change. But no problem, I like every challenge and also take it if possible .
I will upload my code in 5 minutes to the repo. The code is compilable and is running but there are a lot of codes commented out, which needs to be rewrited to DirectX 11 standards. Tomorrow I will continue this work, if I will have any question I will post it here .
I will push my code to a new branch created by myself until the multi-device support will work fine .
If you have any suggestion please write.

I have a strange error on one of my videocards (NVIDIA GeForce GT 640M): when I try to run Ogre with this videocard using the directx 11 RenderSystem I got the following error: "Can't find requested video mode." at OgreD3D11RenderSystem::_initialise, line 803. I tried to run also with the official source and got the same problem. Till today I was using just the Intel HD 4000 videocard from my laptop while running Ogre3D.
Another strange error I have is with the VolumeTextures sample on the DirectX 11 Render System. This is strange because Cherlix can run it and it renders correctly:
error

running sample (cherlix)


I tried to resolve these problems, but haven't made any progress. If anyone have a suggestion please write (or bugfix it commiting to the repo . ).

Regarding the "Can't find requested video mode" - try deleting the ogre.cfg and retry.

I have tried in many times, but it doesn't work. I have the latest beta driver from NVidia.

Well, turn all exceptions on in debug->exceptions - and see what is going on. Also look at the OGRE log.

The issue with the VolumeTextures was the case where two shaders got the same hash code in the RTSS, I fixed it and committed the code.

robert_sasu and I talked about the other issue over Skype - he will explain the issue on this thread later if he wants, but now he understands it.

I discussed today with Assaf Raman and as I have a laptop with Optimus technology from NVidia I can't run on instance of Ogre3D in two different videocards (even if I have those 2.). So I can't test the multi-device support which is going to be written. Because of this I stop working on the multi-device support and move on to the RTSS support and dynamic linkage. After I will manage to get a device in which I will be capable to test the multi-device support I will also finish that work (there is not much work left, around 2, in the worst case 4 days).

About the RTSS support and dynamic linkage, firstly I will start with implementing the dynamic linkage to the DirectX 11 Render System. Dynamically linked methods' performance matches that of static function calls; also, the linking overhead is just that of setting one constant buffer. The feature is designed to reduce the combinatory explosion of number of shader types for different techniques, without sacrificing performance. For example, you can have a single abstract shader for all your material types but just switch the BRDF implementation and light implementations on the fly.

Graphics developers sometimes create large, general-purpose shaders that can be used by a wide variety of scene items. At runtime, the shader conditionally runs code appropriate for the given situation. Unfortunately, these large, general-purpose shaders use general-purpose registers (GPRs) inefficiently, and can be much slower than smaller, more targeted shaders.
Shader model 5 addresses this performance problem by introducing dynamic shader linking. Dynamic linking separates shader code fragments by using interfaces and virtual functions and allows the application to select the fragment to use at draw time. This improves performance by binding only the shader code needed and not the entire large, general-purpose shader.

The cg compiler did implement this feathure ages ago in software and doesn't require shader model 5.0 for this. But HLSL does requiere.

Can you explain more what benefits will this give us? Performance? If so - in what scenario?