Horde3D

Next-Generation Graphics Engine
It is currently 17.10.2018, 15:32

All times are UTC + 1 hour




Post new topic Reply to topic  [ 154 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11  Next
Author Message
 Post subject: Re: OpenGL ES Port
PostPosted: 02.07.2012, 00:41 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Hi attila,

first congratulations on shipping Offroad Legends. I didn't have a chance yet to try it out but it looks great from the videos you posted!

Regarding the remaining OpenGL states in egRenderer.cpp: I'm very busy with work but this shouldn't take too much time, so I can try to take care of it.

The idea is that the states get grouped as in D3D11 (rasterizer, blend, depth/stencil) and encoded in bitfields so that you can easily get a hash with which you can retrieve a d3d state object from a cache in the d3d device wrapper. That way Horde will still remain flexible in terms of render state management (for example shader FX states overwritten by engine code) and the performance impact for the d3d backend would be acceptable.

When do you plan to work on the D3D11 backend so that you would need to have the update?


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 03.07.2012, 07:44 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
marciano wrote:
The idea is that the states get grouped as in D3D11 (rasterizer, blend, depth/stencil) and encoded in bitfields so that you can easily get a hash with which you can retrieve a d3d state object from a cache in the d3d device wrapper. That way Horde will still remain flexible in terms of render state management (for example shader FX states overwritten by engine code) and the performance impact for the d3d backend would be acceptable.


That sounds great.

marciano wrote:
When do you plan to work on the D3D11 backend so that you would need to have the update?


I have already started working on to support the Metro platform, but currently doing it in my spare time. It is not high priority as our target platforms (Windows Phone 8 and Windows RT) are not yet released. Porting other parts of the engine could take 2-3 months probably. So it would be great if after that I could work on horde3d's D3D11 backend.
But I know that you are busy at work and doing this in your spare time.
Thanks again for this great engine!


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 19.07.2012, 16:32 
Offline

Joined: 19.07.2012, 16:17
Posts: 2
Location: Beijing
Volker wrote:
I tried to merge both utOpenGL.h files into one, since there are not so many differences and most of the things needed for other operating systems aren't necessary on IOS since the OpenGL methods are available through the system headers.
I got Horde already running on android (2.3 and above) too, but I haven't cleaned it up yet so it's not in a commitable state. But the implementation was already used in the ElferHeld app from Gelbe Seiten on IOS and Android. We had some trouble creating the default FBOs on android, that's why the global material settings haven't been applied on android, but I didn't have the time to look into it before the release and the missing red shine on Android wasn't a show stopper.
So basically it should work, the only thing is that it should be cleaned up and issues left should be solved (although due to the differences in hardware on android, I guess one should concentrate on the most modern devices and let possible workarounds for missing capabilities up to real projects).


Hi, Volker, thanks for your GLES port,
I've compiled and ran successfully on my iPad2 and the new iPad.
But I find it's so weird that the frame rates of Knight is around 30fps on iPad2 and 20~30fps on new iPad, but it's extremely slow only 5~7fps on new iPad and 7~10fps on iPad2 even when render only one model doesn't change anything.
I can not find why, can you give some suggestions ?


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 19.07.2012, 19:13 
Offline

Joined: 29.10.2010, 14:28
Posts: 46
Location: Hungary
antmanler: maybe your ipad3 was in retina resolution. (2048x1536)
ah, i see your problem is not the difference between ipad2 and 3, but the one-model framerate.
did you check your log? if the app logging in every frame, its influences the frame rate.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 20.07.2012, 04:31 
Offline

Joined: 19.07.2012, 16:17
Posts: 2
Location: Beijing
anchor wrote:
antmanler: maybe your ipad3 was in retina resolution. (2048x1536)
ah, i see your problem is not the difference between ipad2 and 3, but the one-model framerate.
did you check your log? if the app logging in every frame, its influences the frame rate.


I compiled from SDK 5.0 and GLKView default size is 1024x768

It work out when I commented out adding platform scene:
Quote:
H3DNode env = h3dAddNodes( H3DRootNode, envRes );
h3dSetNodeTransform( env, 0, 0, 0, 0, 0, 0, 0.23f, 0.23f, 0.23f );

then the framerate return to normal, about 30fps on ipad3 (in 1024x768) with 100 Smith.

This may result from the geometry file of platform scene, but I still could not find what's wrong.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 28.07.2012, 16:51 
Offline

Joined: 23.07.2009, 21:03
Posts: 51
Location: Germany
Just found this on the Real-Time Rendering Blog:

I can’t say I grok it all yet, but Bringing AAA Graphics to Mobile Platforms (from GDC) has a lot of chewy information on what’s fast and slow on typical mobile hardware, as well as how it works. PDF version on the Unreal Engine site.


This has nothing to do with the previous posts, but I guess this is the right place to share it :)


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 13.10.2012, 12:18 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
marciano wrote:
Regarding the remaining OpenGL states in egRenderer.cpp: I'm very busy with work but this shouldn't take too much time, so I can try to take care of it.


I have started to work on the d3d11 port. Did you have any free time to work on this Marciano ?


A little offtopic:
I have also started to do some optimization on h3dRender. Culling was fairly inefficient as we have 3 drawgeometries (opaque,alphatest,alphablend) in our pipeline and h3dRender currently does the culling for each drawgeom with the same parameters. So I split updatequeues into two function: cull and filter_sort and does the culling only once. It made the culling nearly three times faster.

The distant goal could be something like in this presentation: http://bitsquid.se/presentations/flexib ... tforms.pdf.

h3dRender could have 4 stages:
1. culling visible objects (camera, light and shadow frustums) - probably more cache friendly to cull an object for each frustum at once
2. draw objects into an intermediate command stream
3. sort command stream
4. issue commands to device

stage 1 and 2 could be split into jobs
stage 3 could use some parallel_sort if needed
stage 4 could be parallel on d3d11, use main thread on OpenGL

what do you think about this design?


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 14.10.2012, 22:11 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Hi attila, the render state refactoring was submitted today. All OpenGL calls are encapsulated by the RDI now, so there are no direct gl calls in the Renderer class any more. While this works well in the samples, it definitely needs to be tested in a more complex application though to make sure that no new bugs were introduced. As states are organized similarly to D3D10/11 state blocks, this should make your port a lot easier.

Yeah, optimizing the culling was on the TODO list for a long time. I was thinking of gathering all views into the scene (camera and shadow frustums) in a first pass and then cull scene objects against the list of views, generating a bit mask which describes for each object in which views it is visible. Objects which have a non-zero view mask would go into an update stage where resources for rendering are prepared (updating buffers etc.) and render items are generated. Those get sorted into batches and finally dispatched to the graphics API. This is all quite similar to what you describe and could definitely be parallelized using a job system without too much hassle.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.10.2012, 10:28 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
marciano wrote:
Hi attila, the render state refactoring was submitted today. All OpenGL calls are encapsulated by the RDI now, so there are no direct gl calls in the Renderer class any more. While this works well in the samples, it definitely needs to be tested in a more complex application though to make sure that no new bugs were introduced. As states are organized similarly to D3D10/11 state blocks, this should make your port a lot easier.


Wow. Thanks a lot! This will make a d3d port much easier. I will merge the trunk with my branch and tell if i find any problem.
I will work on a d3d11 port and share the code when i'm finished. Hopefully everything will go smoothly. My only remaning concern is about constant buffers.

marciano wrote:
Yeah, optimizing the culling was on the TODO list for a long time. I was thinking of gathering all views into the scene (camera and shadow frustums) in a first pass and then cull scene objects against the list of views, generating a bit mask which describes for each object in which views it is visible. Objects which have a non-zero view mask would go into an update stage where resources for rendering are prepared (updating buffers etc.) and render items are generated. Those get sorted into batches and finally dispatched to the graphics API. This is all quite similar to what you describe and could definitely be parallelized using a job system without too much hassle.


Great to hear that you were also thinking about something similar. I will post the code when I'm finished, maybe you will find it useful.
I'm also trying to optimize drawrenderables but still without any success. I've tried to optimize the string compares (context, uniform, texture lookup).
I've replaced strings with an id (int) but it didn't give a significant speedup. Maybe I have too small number of materials in my test framework.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.10.2012, 13:57 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
I finished the merging. It seems to work fine, the only problem I had that I don't preserve OGL states between GUI/H3D rendering.

I added the code below to force renderstates sets on the first commitStates().

Code:
void RenderDevice::beginRendering()
{
...
   _curRasterState.hash = 0xFFFFFFFF;
   _curBlendState.hash = 0xFFFFFFFF;
   _curDepthStencilState.hash = 0xFFFFFFFF;
}


some other thing I found while merging(not related to OGL states).
In RenderDevice::createTexture()
instead of tex.memSize = calcTextureSize( format, width, height, depth );
I'm using tex.memSize = calcTextureSize( format, width, height, tex.depth );
because tex.depth is set 1 when type is not texture3d. (depth param is 0 when loaded with loadSTBI)

In RenderDevice.h I think there is no need for virtual destructor and init. (was probably needed when Renderer was a subclass of RendererBase)

Thanks again for this changes.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.10.2012, 16:44 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
I had a strange slowdown with the new version. Framerate was nearly halved.
I'm using PowerVR es2 emulator on a windows7 pc.
It seems the problem is with this lines:

if( !_newBlendState.alphaToCoverageEnable ) glDisable( GL_SAMPLE_ALPHA_TO_COVERAGE );
else glEnable( GL_SAMPLE_ALPHA_TO_COVERAGE );

the alphaToCoverageEnable was disabled, but it seems that even the glDisable caused the framerate drop.
This is probably an emulator/driver bug.

After commenting out these lines the new version is 6-7% faster than the previous h3d version. (state caching seems to work well)


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.10.2012, 23:24 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Thanks for your feedback, good to see that the changes are an overall win then! The small issues you mentioned should be fixed now.

For mobiles it might even be worth trying if setting each sub-state within the blocks only when it really changes gives and advantage, although that certainly depends on the driver and how it handles redundant state changes.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 16.10.2012, 09:18 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
Thanks for the quick update.

One small thing I found about the state array trick:
Code:
   uint32 oglBlendFuncs[8] = { GL_ZERO, GL_ONE, GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_DST_COLOR, GL_ZERO, GL_ZERO };
   glBlendFunc( oglBlendFuncs[_newBlendState.srcBlendFunc], oglBlendFuncs[_newBlendState.destBlendFunc] );

   uint32 oglDepthFuncs[8] = { GL_LEQUAL, GL_LESS, GL_EQUAL, GL_GREATER, GL_GEQUAL, GL_ALWAYS, GL_ALWAYS, GL_ALWAYS };
   glDepthFunc( oglDepthFuncs[_newDepthStencilState.depthFunc] );


Currently the arrays are filled at each call (tested on msvc9 relase build). Adding a static and maybe const keywords eliminated this.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 21.04.2013, 21:27 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
Dear OpenGL ES developers.

I found two es2 implementations in the community branch(ES_Test, Horde3D_IOS), I would like to ask permission to use them in horde3d-x github repo GLES2 branch. I would like to merge them with my es2 implementation.

Probably the licensing allows this, but I don't want to "steal" anybody's work.

Thanks


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 21.04.2013, 22:12 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1149
Location: Germany
Go ahead regarding the IOS code. I would be happy if it would be merged into a unified ES 2.0 branch. Not sure about who had contributed to the ES_Test branch. I'm currently on a tablet where svn browsing is no fun. But I guess there should be no problem, as far as I made contributions (can't remember) there is no limitation from my side.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 154 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group