Finally, a DirectX 10 video driver for Irrlicht

robmar · Post by **robmar** » Fri Aug 29, 2014 8:52 pm

O will do

Granyte · Post by **Granyte** » Fri Aug 29, 2014 9:39 pm

Nadro wrote:Granyte can you share your config (CPU, GPU, OS and drivers version). DX11 perf looks great, but with OGL something is wrong. Maybe are you use drivers from Windows Update?

Operating System:Windows 8.1

CPU Type:AMD FX(tm)-8350 Eight-Core ProcessorCPU Speed:4 GHz

System Memory:34.25 GB

Video Card Model:AMD Radeon HD 7970 Series x2 cfx

and i'm using catalyst 14.7 rc1

and the drop of performance is only in the fvf

in 1.8.1 ogl and dx9 both make 2400 fps so something fishy is going on even in dx9

EDIT: I just removed something I though was fishy from the dx11 driver now it's going at 4k fps in the terrain example

I even have instancing almost working as multiple VB are already supported so far there are two things bothering me first the fixedpipeline shader got into the .h way to early not even half of it is working correctly and editing it require recompiling

and blending the damned blending is driving me crazy example 10 simply does not work

EDIT 2 I found the culprit for the performance decrease on dx9 the is required update interphase was not completed forcing the dx9 driver to upload every frame and not knowing this I rewrote the old changed ID system in dx11 ill finish implementing the interphase and make dx11 complient with it

I should have this completed tonight ill upload a full download with this fix and dx11 instancing

EDIT 3 : it was really that the drivers were uploading every frames causing a hudge slowdown all drivers are up to the new system
and after changing to the new system dx11 does 4000 -4100 fps, dx9 3600-3700 fps and ogl at 2600 -2300 fps

that maked the opengl driver on par with the one in 1.8.1 but gives a nearly 2x boost to dx9

i'm off to add instancing and volume texture to dx11

EDIT 4: I got carried away and spent the last few hours hunting the bug I had been talking for ages about rtt turn out the driver was not properly recreating depthbuffers after clearing them now this is fixed the driver was also not properly matching depth buffers with rtts as they need to be the exact same size in dx11 so back to instancing

robmar · Post by **robmar** » Sat Aug 30, 2014 9:40 am

Okay now I remember I had this same problem the last time:

"Re: Finally, a DirectX 10 video driver for Irrlicht

Postby Granyte » Wed Apr 23, 2014 12:17 pm

my suggestion for a quick prototyping use the visual studio 2012 solution and downgrade the platform to vc10 (visual studio 2010)

ill fix the solutions after the en of the week when my session ends"

Was the VS2010 config fixed, or is their a fix so that D3D_SHADER_MODEL gets found?

Nadro · Post by **Nadro** » Sat Aug 30, 2014 10:11 am

Thanks for info, shader-pipeline may be slower than trunk in ogl 2.1 due to vertex descriptor calls, however with OGL3.x and up difference will be gone. For fixed function shaders you may use some code from ogl-es branch - COGLES2FixedPipelineRenderer.* files.
OGLES2 driver uses IShaderConstantSetCallBack, so code may be shared across other drivers (we may even rename this classes from COGLES2FixedPipelineRenderer to more global CFixedPipelineRenderer), however translate from GLSL to HLSL is required for files from "media/Shaders".

BTW. If you will be able to post new patch, I could merge it with shader-pipeline (I'll work with Irrlicht at this week), because as I see your previous patch is outdated now

robmar · Post by **robmar** » Sat Aug 30, 2014 10:19 am

I can translate the shaders if needed. I´ve already translated quite a lot of more complex one. But can someone help me on the VS2010 D3D_SHADER_MACRO?

Nadro · Post by **Nadro** » Sat Aug 30, 2014 4:42 pm

This macro is available in D3DCommon.h, however you need Win 8.x SDK or VS2012.

Granyte · Post by **Granyte** » Sat Aug 30, 2014 7:46 pm

Nadro wrote:
BTW. If you will be able to post new patch, I could merge it with shader-pipeline (I'll work with Irrlicht at this week), because as I see your previous patch is outdated now

I can post a patch do you wan texture array and volumes with it?

The solution has been fixed as far as I know but the issue you have is because you don't have the dx sdk

robmar · Post by **robmar** » Sat Aug 30, 2014 7:51 pm

So I just need win8 sdk, or vs2012 as well?

Nadro · Post by **Nadro** » Sat Aug 30, 2014 7:58 pm

Cool, I'll merge this patch today or tomorrow

Texture arrays and volume textures may stay in CD3D11*.h/cpp files, however in a headers like a IVideoDriver.h etc and CNullDriver.h/cpp it will be better to remove those stuff. I want to add texture volumes and texture arrays to trunk instead of shader-pipeline at first and next I'll merge changes from trunk with shader-pipeline. Of course currently texture arrays and texture volumes will be not available outside D3D11 driver classes, but if we'll leave this stuff here you will be able to make patches related to D3D11 faster (without remove texture arrays and texture volumes stuff from CD3D11 files for each patch).

robmar wrote:So I just need win8 sdk, or vs2012 as well?

As I remember DX11 libs are included in VS2012 for Desktop, but I may be wrong, so please install the latest Win 8 SDK.

Granyte · Post by **Granyte** » Sat Aug 30, 2014 8:34 pm

Ilss see how cleanly I can remove the additional textures from the rest because most of my work is on dx9 for now and I have a couple fix on dx9

EDIT great Microsoft depreceated d3dx11 so the methode

void CD3D11MaterialRenderer::createResources(ID3D10Blob* code, E_SHADER_TYPE type)

does not work when compiling irrlicht against the windows 8 sdk I made it work by force loading d3dcompiler_43.dll instead of the last one but this is not a valid way for future work

hendu · Post by **hendu** » Sun Aug 31, 2014 8:16 am

Is it compatible with my GL texture arrays? If so, it should be ok to have in IVideoDriver etc.

Nadro · Post by **Nadro** » Sun Aug 31, 2014 8:36 am

@Hendu
In upcoming days I want to implement many of your patches from a tracker (texture arrays too) to trunk and next merge those changes with shader-pipeline, thats why I don't want to have texture arrays stuff in shader-pipeline headers now (less conflicts at merge).

@Granyte
You can post D3D9 fixes too, so I'll apply them to trunk.

Granyte · Post by **Granyte** » Sun Aug 31, 2014 4:33 pm

hendu wrote:Is it compatible with my GL texture arrays? If so, it should be ok to have in IVideoDriver etc.

Yes it does your patch is included i only slightly expanded on it to have more texture types

Nadro wrote:@Hendu
In upcoming days I want to implement many of your patches from a tracker (texture arrays too) to trunk and next merge those changes with shader-pipeline, thats why I don't want to have texture arrays stuff in shader-pipeline headers now (less conflicts at merge).

@Granyte
You can post D3D9 fixes too, so I'll apply them to trunk.

Alright then i'll try to post separate patches for everything so you can use the texture stuff on the trunk an the rest here

EDIT: i just found an other nasty bug in the d3d11 driver reset code working on it

EDIT: the driver is not properly uploading vertex texture also I just found out rather then generating mipmaps properly the driver only upload the mips zero then sets all texture as rendertarget
ill upload my patches later today

AReichl · Post by **AReichl** » Wed Sep 24, 2014 10:07 am

Only a (silly?) question: what happened to 'drawVertexPrimitiveList' in the D3D9 driver part? It's there in D3D11 again.
In only ask because i cannot compile some examples ( namely 03.CustomSceneNode which uses 'drawVertexPrimitiveList', and also 21.Quake3Explorer which uses 'removeAllHardwareBuffers' ).

Nadro · Post by **Nadro** » Wed Sep 24, 2014 11:42 am

In shader-pipeline we use mesh buffers instead of pure vertex arrays. You should use drawMeshBuffer method instead of drawVertexPrimitiveList.