Finally, a DirectX 10 video driver for Irrlicht

[Granyte]

There is no promise about variable in dx9 because originaly dx9 was ment for fixed piplines so having a variable travel along the pipeline was pointless the same goes for textures

And while we are at it I think texture binding at diferent stages should be explicit in dx9 and 10 because in dx9 the weight of binding a texture to all stage is quite noticable and you can only bind 4.

in dx11 i tried binding all texture to all stages and the performance hit was horrible

EDIT NVM geometry shaders are working perffect i just haad modified my shhader to work without them

[robmar]

Why does binding textures hit performance? Arent they in gpu video memory...

[robmar]

And dx10 up supports texture arrays....

[Granyte]

the performance hit comes from two thing irrlicht need to bind texture and transforms
and each of these is an api call with quite a bit of overhead and the hit comes from the fact that i had to bind 16 texture per shader stage plus 16 sampler state in short 16*2*3 so 96 api calls if we add hull and domain shaders to the thing it's just gonna get worst.

beside even if we use texture array and bind only 1-2 texture that is still 1-2 texture bind call per shader stage and that overhead could be avoided

yes dx10 support texture array so does OGL, dx9 support 3d texture and cube maps but all these are unexposed with irrlicht

Alright now that geometry shaders are back on i'll be implementing real instancing support to dx11 with my FVF patch for multiple vertex buffers

[robmar]

But there has to be a solution to this. Binding to cpu memory textures each frame cannot be the normal process. Textures updated each frame by the user app will already be in gpu memory, so no need to reload them.

what's needed to do this the best way?

[Granyte]

They are not actually uploaded each frames but each time you bind a texture DX cheq where it cached it and decide to upload it or not

But because in dx the stages are independent you can bind a different texture to each stages so the best way to go would be to expose something like material texture for stage X but that is very unlikely because as far as I know OGl can't bind to different stages.

so next best thing would be to have a flag to enable or disable uploading texture on each stage.

also I noted that the dx11 driver does not really use the FVF it still use

Code: Select all

setRenderStates3DMode(vType)

so using custom vertex format with it is for now impossible

[robmar]

So where is the tex bind overhead? What about ogre, can you use code from its driver?

[Granyte]

the driver already kind of optimise if it uploads to the shader or not

Code: Select all

if(resetViews)
        Context->PSSetShaderResources(0, MATERIAL_MAX_TEXTURES, shaderViews);
 
    if(resetSamplers)
        Context->PSSetSamplers(0, MATERIAL_MAX_TEXTURES, SamplerStates);

but it does not upload to the non pixel shader stages

[robmar]

So is the existing DX9 driver going to still offer better FPS than this new DX10/11 version, and if so how much difference in performance will there be?

[Granyte]

As long as i don't enable vertex texture they should be similar with certain usage faster and others slower

How ever if i enable them people using multiple texture layers will face a hudge perf hit

[hendu]

You cannot analyze the shader to see if it reads textures? That's what GL drivers do internally.

[Granyte]

I guess that could be possible but i's beyond my knowledge atm i'll lool into it

[zerochen]

also I noted that the dx11 driver does not really use the FVF it still use

Code: Select all

setRenderStates3DMode(vType)

so using custom vertex format with it is for now impossible

i guess you think it because this is using E_VERTEX_TYPE vType? vType should be changed later to an u32 but this needs changes to all drivers first. for now it is setted like this

Code: Select all

(E_VERTEX_TYPE)vertexBuffer->getVertexDescriptor()->getID()

so vType isnt fixed to the predefined vertex types.

back to the constant buffer:
so it doesnt matter if they are in the same file? if they have the same name they are shared.
if there is a constant buffer only in the gs we need a separate function to set the vars like setVertexShaderConstant just for gs, hs, ds and cs?

regards
zerochen

[Granyte]

Thanks for the info about vType instancing should be working I just have not yet created a proper shader for it in dx11 so the driver scream about input layout ill get to it tomorrow.

One last thing the blending on example 10 is not working properly any one knows how to get it working? it seem like transparent material are zwritting

[robmar]

How about making a slight mod to take the core (old asm) shaders out of the source headers, and have them loaded from separate files? Also maybe drop having opengl and hsls and just use cg shaders, or make that optional. I could convert some of them to C and also to Cg.