Ogre Forums

DirectX11 is eight year old. Our GPUs is dev. far past DX11

The GPUs are multithreaded and the CPU is multithreaded, but current DX11 drivers is actually not the optimal way to talk to modern graphics cards.
Not even on a IPAD...

Apple has developed Metal for IOS
AMD has developed Mantal for AMD VPUs

Microsoft is doing the exact same as Metal and Mental even if they insist calling it DirectX12.
It's way different than DirectX11...

It enables each thread in the CPU to access threads one to one in the GPU.
Drivers size is cut to half. Speed increases. Driver bugs decreases, application programmers have to take more responsibility
and do the stuff that the driver used to handle in the background.

There is new state object bigger ones and stacks. Command queues.

But basically the API and drivers isn't built on the notion of bind points like DirectX11 is.

It allows the application to get full control of the actual hardware, and compute. More stuff can be done with compute.
Or should be done with compute. It's cheaper and faster.
Old truth of what was a fast way to do things in shader programming don't hold true anymore.
High level shading code expands to new low level code today. That takes longer to execute.

DirectX11 is eight years old.
And I seam to write this sort of rants each time a new graphics API version is released.

But it's time to revise Ogre2.0 and Ogre1.9 and get them up to speed with the current development in multithreaded hardware.

Or be left in the dust.

Lee04 wrote: But it's time to revise Ogre2.0 and Ogre1.9 and get them up to speed with the current development in multithreaded hardware.

Its a very turbulent time in the graphics world thats for sure! However your point about Ogre2.0 sounds like you have not been following dark_sylinc's work too closely as he has been looking at this in quite a lot of detail, for example;
http://ogre3d.org/forums/viewtopic.php?f=25&t=81060

My worry is that, although I want Ogre 2.0 to be complete and polished now , I am little concerned that we should wait for this, Mantel, Metal, DX12 & OpenGL AZDO thing to sort its self all out before deciding on the final architecture of Ogre 2.0. And no I dont really known what I mean by that!!

al2950 wrote:

Lee04 wrote: My worry is that, although I want Ogre 2.0 to be complete and polished now , I am little concerned that we should wait for this, Mantel, Metal, DX12 & OpenGL AZDO thing to sort its self all out before deciding on the final architecture of Ogre 2.0. And no I dont really known what I mean by that!!

Sometime I wonder if trying to find ways to make very simple to write a new renderer would help people interested but not necesserally in the Ogre team to write one. I have no clear idea of what could be done to help but I think it would be related to the renderer apis design and as it's being touched a bit these days for Ogre 2.x (if I understood correctly), it's not the right time yet to focus on that I guess.

Lee04 wrote:But it's time to revise Ogre2.0 and Ogre1.9 and get them up to speed with the current development in multithreaded hardware.

Or be left in the dust.

It seems like you haven't been following Ogre development closely (2.0 is in early stages and 1.9 is already stable). Also this seems like almost a duplicate of a previous post of yours about DX12, where the sky is falling if everyone doesn't get on board right away (even though I don't think the early access program has even started).

I don't see any reason to invest in Mantle ... whole bunch of effort for just 20% of desktop users. Better to spend effort on GL and DX which need plenty of work. Metal is cool, I haven't had a chance to look at much info about it, but again the market share of apple products is quite low.

Also how much can you really expect from a small team with a large task who publishes their work under MIT? It's up to you to jump in and help make things happen if you want them badly.

c6burns wrote:Also how much can you really expect from a small team with a large task who publishes their work under MIT? It's up to you to jump in and help make things happen if you want them badly.

+1

Whining on forums is not what implements new features in open source projects. Even if you do it twice in a row

I am a fraid it's more than two times....try five times.

Last time wikopedia had even removed the current API....before Ogre changed API

Yes, everyone should stop the valuable work they are doing to get on board the new graphics APIs that aren't released yet, or the new graphics APIs that are of limited use, or maintaining a wikipedia page. I wish I was a doctorate student so I could think of these great recommendations for how other people should spend their time

We are NOT talking about the API's per say, but rather the Ogre engines structure to support different APIs.
If we do a structure that suppers only DX9 like Ogre once did. It had a hard time adopting it to DX11.

DX11 was a long haul and still I not certain it's implemented in a DX11 specific architecture like it's suppose to be.
Done correctly DX11 implementation should be faster than DX9...

AMD Mantal and IOS Metal is very much finished and used by DIce for instance and Epic.
The general engine structure to support them and DX12 will be much the same. You don't need to have DX12, to start shifting the Ogre design towards
the new APIs.

One example mentioned about Apples Metal on Ipad air was 4000 draw calls per frame on a small device like that.

Don't kill the messenger...

For each person that writes here that they don't support early adaptation of new graphics trends there are 10 if not 100 that does.

A lot of people with the skills and a lot of time on there hands with a burning desire to learn the latest stuff and are looking for a
perfect opportunity to show of there skills exist in this community.

Ogre community is the best of places to show what you are capable of.
I have contributed advanced code to Ogre. So I hope others will as well.

Lee04 wrote:AMD Mantal and IOS Metal is very much finished and used by DIce for instance and Epic.

Yes, but only by those AAA guys. And only because they can afford having a team doing nothing but trying this out, even if it is a potential waste of resources.
And I am 100% convinced that they received a lot of direct help from the Mantle devs. Mantle or Metal are not exactly open books like OpenGL or DirectX where everyone can just look up and find help in how to implement something.

The success of such APIs is decided by those with too much money. Only if AMD can push hard enough to establish the API everywhere, will it become viable for developers of software like Ogre to adapt it.
I'm not saying Mantle will never reach such a status, but we have no idea if it does. And frankly, AMD having to push mantle like that to have a few AAA devs tackle it is not exactly a sign of "it's so good and well supported everyone would be mad not to use it". It's still not clear what Nvidia will do, for example.

See the fight of BluRay vs... what was that other thing? BluRay won, because Sony threw in more money and had a better marketing strategy.
Consumers and producers of players could only sit there and wait for the winner. Or be "bribed" by either side to produce players for their format.

Now Ogre is in such a producer position right now.
We do not have those resources to just start implementing Mantle, nor did AMD come to us to pay us to implement a Mantle renderer (well, afaik).
Hence we wait, or rather focus on what we have today. And that is mostly OpenGL for all platforms (+DirectX for Windows (Phone)).
Spending our very limited resources (the free time of awesome people like dark_sylinc) on something as risky as Mantle would be pure nonsense from a management perspective.

Also, as many others already stated, Ogre 2.0 will have a very new and different structure. Nobody will prevent you or someone else from writing a Mantle or Metal renderer once it is out.

I have been extremely busy past week I barely had time to work on AZDO Ogre. I was supposed to commit some AZDO source (not currently running but compiling) but I was flooded with client work.

Get happy because this AZDO code I'm writting is very low level, and most of it should be reusable for DX12, as soon as we are able to get our hands on it.
It performs vertex and index buffer memory management entirely on our side, synchronization is explicit (to keep stalls to a minimum).
Texture buffer management hasn't been refactored, however the HLMS already creates texture arrays to limit the number of rebinds per draw (automatic packing).

It's far from finished though. And a New Entity class will slowly start phasing out the old Entity class, as the buffers and mesh loading methods will be just very different (new Entity = super speed).
It's not going to be an easy transition, but will be worth it; it's basically the change that you're demanding in this post.