Finally, a DirectX 10 video driver for Irrlicht

[Radikalizm]

On compute shaders, I don't think they belong in a 3d engine.

Why not? They've proven themselves countless times in many advanced rendering systems, so why not use it? Just because they use the term 'general purpose GPU' doesn't mean these shaders can be applied to graphics.

[hybrid]

Oh hey, will irr take part in the coming gsoc?

No, we applied for several times, but now I don't have any fun nor time for it anymore.

[hendu]

@hybrid

Sad, it would've been a great way to spend the summer.

@Radikalizm

By that reasoning anything could be applied to graphics? Heck a lava lamp could be hooked via a webcam to act as a random number source (been done, but not something that should be in irrlicht either IMO).

OpenCL being able to run on gpus isn't a reason to wrap it, since it also runs on cpus and specialized hw such as Creative's or Tilera's. The benefits for irrlicht would be minimal, as you still need a lot of setting up. I'm not familiar with the dx11 equivalent, but I assume it has a cpu path as well.

Also added dependencies, be it W7 or the opencl libs.

[Radikalizm]

@hybrid

Sad, it would've been a great way to spend the summer.

@Radikalizm

By that reasoning anything could be applied to graphics? Heck a lava lamp could be hooked via a webcam to act as a random number source (been done, but not something that should be in irrlicht either IMO).

OpenCL being able to run on gpus isn't a reason to wrap it, since it also runs on cpus and specialized hw such as Creative's or Tilera's. The benefits for irrlicht would be minimal, as you still need a lot of setting up. I'm not familiar with the dx11 equivalent, but I assume it has a cpu path as well.

Also added dependencies, be it W7 or the opencl libs.

If you're already using the D3D11 libraries for rendering you wouldn't need any additional dependencies to include compute shaders, they'd already be right there ready for use. What I'm getting at is that if you have this massive parallel processing power of a GPU at your disposal (that is, if your application isn't already flooding the GPU) to speed up calculations that you'd normally do on the CPU, then why not use it? Everything you need to do this is right there at your disposal. It's completely different from 'hooking up a webcam to record a lava lamp for random number generation' since that technique would, in most cases, not be beneficial at all to your situation, while compute shaders probably would be
Even if you only were to make compute shaders available to people using the engine rather than actually using it in the engine internally it would still offer some great benefits since it opens up a huge amount of possibilities for next-generation rendering techniques. Again, if it's right there at your disposal, then why actively choose not to use it?

[Granyte]

it would simply be dumb not to make them availible
i mean if we include dx11 but don't make them availible any one who would like to use them for AI or even texture work (without using a god damn screen quad), procedural generation physic or W/e in a game or a rendering engine that could use them

there are many feature where a simple pass through to the driver would be usefull

[hendu]

I'm not saying they're not useful; I'm saying they are general computation, which I see as out of scope for irrlicht's target of 3d rendering.

[mongoose7]

I agree. You would also have to provide code for the setup.

There is no DX1X driver, after two posters said they were working on one. It seems to me, at this stage, a minimal driver is required *now*, then there can be a debate about extending it. Irrlicht is changing at a glacial pace but everyone wants everything in it. I just cannot understand this.

[ACE247]

We need to rework maybe the way people see Irrlicht, not keep support for the absolutely ancient hardware for example, Sure WinXP is necessary, but there needs to be a minimalist style old-hardware compatible reduced version of a larger more capable Irrlicht. So why doesn't one of the admins maybe create a sticky post to better explain some more detail.

A good Idea would be to get more outside support for irrlicht, for instance advertising Irrlichts capabilities, through a community Game Tech Demo, I would have a large variety of artwork(meshes, textures, sound effects) and story lines available we could use. PcOde's Blender to Irrlicht script(Its one of the best I've seen, its basically a level editor and all in Blender for Irrlicht) is also a great thing we should maintain and directly include with irrlicht, a strong Artist to engine content pipeline is quite important for potentially ineterested people/parties.
Any more ideas from you guys out there? Should we maybe move this discussion to a new Thread?

[RdR]

We need to rework maybe the way people see Irrlicht, not keep support for the absolutely ancient hardware for example, Sure WinXP is necessary, but there needs to be a minimalist style old-hardware compatible reduced version of a larger more capable Irrlicht. So why doesn't one of the admins maybe create a sticky post to better explain some more detail.

Agree, but the main reason I think is that no developer wants to (or afraid to ) make a big API change ( which is necesarray ? for DX10+, Flexible vertex format )
But if you want to go with current time, will have to make some.

[aaammmsterdddam]

I don't see the point why not to keep support for ancient hardware....
yet again. I am the way I am (I like having dx 8 support! even though no sane person would use it.)

[ACE247]

They way I know you, you just want features for the sake of having features and being able to brag about them....

[Radikalizm]

I don't see the point why not to keep support for ancient hardware....
yet again. I am the way I am (I like having dx 8 support! even though no sane person would use it.)

Because if you want to support old hardware you have to make sure that the API will always stay compatible with said hardware. When you throw in support for newer hardware you will have to make sure that your API supports both without too many workarounds or exceptions, and this becomes exceedingly difficult especially when we're talking about the major differences between DX9 (and predecessors) and DX10/11

[hybrid]

No, that's not true. What we basically do is to define a high-level API (IVideoDriver) and the actual "low-level" drivers in the actual driver implementations. I don't see any reason why this is not possible for dx9 and dx1x at the same time. There may arise features which are not possible for one or the other, but that happened to dx9/opengl also. Eihter we can work around such things with alternative implementations, or there are some things missing for some drivers. But there's no general limitation that a low-level API can under no circumstances implement the high-level interface.

[fmx]

There is no DX1X driver, after two posters said they were working on one. It seems to me, at this stage, a minimal driver is required *now*, then there can be a debate about extending it.

Agreed, lets try to get a minimal DX10 or 11 driver into irrlicht first and worry about implementing all the other low-level features later.

So with that in mind, what would should a minimal driver be capable of?
IMO
- Setting up a render window
- view transforms
- rendering triangle primitives (ideally buffers too but not so important) via shaders
- textures
- basic material properties

That should be enough to get the ball rolling, I think

[Radikalizm]

No, that's not true. What we basically do is to define a high-level API (IVideoDriver) and the actual "low-level" drivers in the actual driver implementations. I don't see any reason why this is not possible for dx9 and dx1x at the same time. There may arise features which are not possible for one or the other, but that happened to dx9/opengl also. Eihter we can work around such things with alternative implementations, or there are some things missing for some drivers. But there's no general limitation that a low-level API can under no circumstances implement the high-level interface.

Maybe I didn't explain what I meant exactly all too well, I know that it's perfectly possible to have a DX9 and DX10/11 driver at the same time, having built this from scratch myself in my engine (although I dropped support for DX9 some time ago). I'm completely aware of irrlicht's interface <-> implementation model

Maybe I should've mentioned actual implementations instead of interfaces, it's true that you can just not implement a feature provided by an interface if the underlying implementation does not support it, but the more features are added in an implementation (and D3D10/11 provides a decent amount of new features in comparison to D3D9) the more functionality you'll have to provide in your interface, which in turn will create more and more unimplemented functionality for older back-ends. This can be brought down to a minimum with a good design, but it will never be eliminated completely.
There's also a matter of varying performance based on how your functionality is implemented, emulation of older/newer functionality, executing code on the CPU/GPU , how much 'low level' control you want to give the developer, etc. These things are certainly not impossible to overcome, but the overall complexity and potential overhead grows, not to mention the user of the engine having to keep in mind which implementation provides which functionality and at which quality.