Horde3D • View topic - OpenGL ES Port

View unanswered posts | View active topics

Board index » Horde3D Development » Developer Discussion

All times are UTC + 1 hour

OpenGL ES Port

Page 3 of 11

[ 154 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6 ... 11 Next

Print view

Previous topic | Next topic

Author

Message

MistaED

Post subject: Re: OpenGL ES Port

Posted: 04.06.2010, 03:57

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

Yeah I noticed a lack of draw_buffers in the main spec and glext header which is a pain. To get around it I just forced it never to make more than one color attachment and I'll just need to make sure to never increase numbufs in the pipeline on any render targets for now (I think just sticking to the forward renderer will do).

There were other things to get passed like the debug drawings and shadowmap creation (for now) but the next snag is how textures are streamed or VBOs are cloned in horde, there's a lack of things like glGetTexImage, glGetCompressedTexImage & glGetBufferSubData (just glancing through, these are useful for cloning data from opengl while ES favours your own code managing the clones or something).

_________________
-Alex
Website

Top

Volker

Post subject: Re: OpenGL ES Port

Posted: 04.06.2010, 08:40

Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany

I just took a look at the libGLESv2.dll of the HTC Leo (HD2) and checked what methods it exports. Seems like there is no glDrawBuffers/glReadBuffers too.

Code:

 glActiveTexture
glAlphaFuncAMD
glAttachShader
glBeginPerfMonitorAMD
glBindAttribLocation
glBindBuffer
glBindFramebuffer
glBindRenderbuffer
glBindTexture
glBlendColor
glBlendEquation
glBlendEquationSeparate
glBlendFunc
glBlendFuncSeparate
glBufferData
glBufferSubData
glCheckFramebufferStatus
glClear
glClearColor
glClearDepthf
glClearStencil
glColorMask
glCompileShader
glCompressedTexImage2D
glCompressedTexImage3DOES
glCompressedTexSubImage2D
glCompressedTexSubImage3DOES
glCopyTexImage2D
glCopyTexSubImage2D
glCopyTexSubImage3DOES
glCreateProgram
glCreateShader
glCullFace
glDeleteBuffers
glDeleteFencesNV
glDeleteFramebuffers
glDeletePerfMonitorsAMD
glDeleteProgram
glDeleteRenderbuffers
glDeleteShader
glDeleteTextures
glDepthFunc
glDepthMask
glDepthRangef
glDetachShader
glDisable
glDisableVertexAttribArray
glDrawArrays
glDrawElements
glEGLImageTargetRenderbufferStorageOES
glEGLImageTargetTexture2DOES
glEnable
glEnableVertexAttribArray
glEndPerfMonitorAMD
glFinish
glFinishFenceNV
glFlush
glFogfvAMD
glFramebufferRenderbuffer
glFramebufferTexture2D
glFramebufferTexture3DOES
glFrontFace
glGenBuffers
glGenFencesNV
glGenFramebuffers
glGenPerfMonitorsAMD
glGenRenderbuffers
glGenTextures
glGenerateMipmap
glGetActiveAttrib
glGetActiveUniform
glGetAttachedShaders
glGetAttribLocation
glGetBooleanv
glGetBufferParameteriv
glGetBufferPointervATI
glGetBuffersAMD
glGetError
glGetFenceivNV
glGetFixedvAMD
glGetFloatv
glGetFramebufferAttachmentParameteriv
glGetFramebuffersAMD
glGetIntegerv
glGetPerfMonitorCounterDataAMD
glGetPerfMonitorCounterInfoAMD
glGetPerfMonitorCounterStringAMD
glGetPerfMonitorCountersAMD
glGetPerfMonitorGroupStringAMD
glGetPerfMonitorGroupsAMD
glGetProgramBinaryOES
glGetProgramBinarySourceAMD
glGetProgramInfoLog
glGetProgramiv
glGetProgramsAMD
glGetRenderbufferParameteriv
glGetRenderbuffersAMD
glGetShaderInfoLog
glGetShaderPrecisionFormat
glGetShaderSource
glGetShaderiv
glGetShadersAMD
glGetString
glGetTexLevelParameterivAMD
glGetTexParameterfv
glGetTexParameteriv
glGetTexSubImageATI
glGetTexturesAMD
glGetUniformLocation
glGetUniformfv
glGetUniformiv
glGetVertexAttribPointerv
glGetVertexAttribfv
glGetVertexAttribiv
glHint
glIsBuffer
glIsEnabled
glIsFenceNV
glIsFramebuffer
glIsProgram
glIsProgramBinaryAMD
glIsRenderbuffer
glIsShader
glIsTexture
glLineWidth
glLinkProgram
glLogicOpAMD
glPixelStorei
glPolygonOffset
glProgramBinaryOES
glReadPixels
glReleaseShaderCompiler
glRenderbufferStorage
glSampleCoverage
glScissor
glSelectPerfMonitorCountersAMD
glSetFenceNV
glShaderBinary
glShaderSource
glStencilFunc
glStencilFuncSeparate
glStencilMask
glStencilMaskSeparate
glStencilOp
glStencilOpSeparate
glTestFenceNV
glTexImage2D
glTexImage3DOES
glTexObjectStateOverrideiAMD
glTexParameterf
glTexParameterfv
glTexParameteri
glTexParameteriv
glTexSubImage2D
glTexSubImage3DOES
glUniform1f
glUniform1fv
glUniform1i
glUniform1iv
glUniform2f
glUniform2fv
glUniform2i
glUniform2iv
glUniform3f
glUniform3fv
glUniform3i
glUniform3iv
glUniform4f
glUniform4fv
glUniform4i
glUniform4iv
glUniformMatrix2fv
glUniformMatrix3fv
glUniformMatrix4fv
glUseProgram
glValidateProgram
glVertexAttrib1f
glVertexAttrib1fv
glVertexAttrib2f
glVertexAttrib2fv
glVertexAttrib3f
glVertexAttrib3fv
glVertexAttrib4f
glVertexAttrib4fv
glVertexAttribPointer
glViewport

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 04.06.2010, 09:02

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

No glGetTexImage and friends either. So far I've been making an utOpenGLES source and header and using the glext class to put the ES2.0 specific extensions in there and only putting in what ES2.0 exposes, which I can share here once I get back onto my desktop.

_________________
-Alex
Website

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 05.06.2010, 06:55

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

Just curious, in what cases would

Code:

bool RendererBase::getTextureData( uint32 texObj, int slice, int mipLevel, void *buffer )

be used? For if the API user wanted to copy out an existing texture to client memory or is it for streaming purposes? If you were to just render and never needed to retrieve texture data in your code, would this call never be used anyway?

_________________
-Alex
Website

Top

marciano

Post subject: Re: OpenGL ES Port

Posted: 07.06.2010, 23:46

Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217

At the moment, it is only used for reading back the texture via the resource API. I think you can just ignore it for now. We can put together a list of all the things that are not supported by ES 2 and decide later what to do with them.

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 08.06.2010, 13:02

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

Thanks for the info Marciano it is very much appreciated!

Well so far I've got it to compile, whether it will work or not is another thing entirely (probably not)! I'm just reading over the PVR format spec and adding support for that. I didn't realise the .pvr format container can house pretty much every format you could think of even DXTC & cubemaps! It might be handy to have PVR support for desktop builds (provided PVRTC isn't used).

The DDS code is a good reference for me to base the PVR code from so I'll just add an else if in-between the DDS code and the stbi loader code.

For abstraction of the APIs, will you be making alternate egRenderBase's and move utOpenGL to the Shared directory or some other directory next to future utOpenGLES & utWhateverAPI? Most likely my code wouldn't be a good fit for integration, I'm only doing this as an exercise to see how GL works and the differences between GL & ES and so far I've learned a lot from the experience.

_________________
-Alex
Website

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 09.06.2010, 02:19

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

Ok up to occlusion queries for the AABB-type stuff.

Seeing as there's no occlusion queries in OpenGL ES 2.0, would this be replaced with like a software implementation perhaps using bullet instead, or perhaps it isn't needed because the tile-based deferred renderer can do this job for you for free, provided that you don't use any alpha discards or alpha blends in the first pass?

Thanks all!

_________________
-Alex
Website

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 10.06.2010, 16:14

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

I feel like I'm my own monologue here

So far I've got a context running on my phone and Horde is rendering (yay!) just all the shaders except for the internal ones are failing (nay!).

I did a simple thing and just put mediump in front of all the fragment shaders in .glsl and .shader and that seemed to fix the internal engine shaders and the overlay shader. The overlay shader compiles fine but I disabled them because they use GL_QUADS internally (shouldn't be too difficult to change that to GL_TRIANGLES, just haven't got to that yet).

Thought I'd share my update, and if anyone has any other tips on converting desktop GLSL to ES 2.0 GLSL that would be great! Pretty much all the vertex shaders aren't compiling, so I think I should attack the vertCommon and VS_GENERAL in model.shader first.

_________________
-Alex
Website

Top

Volker

Post subject: Re: OpenGL ES Port

Posted: 10.06.2010, 18:42

Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany

First thanks a lot for your update posts. I always read them with great interest. Concerning the precision modifier in the shaders I can't propose a better solution than having seperate shader files for es and desktop. Although I think I read something about that those modifiers become part of Desktop glsl too in the future, but since the possibilities of ES glsl is limited anyway I think it would bee also ok to have different shaders.

If you want I could create a community branch account for you, since I guess I won't have much time to work on the ES branch I created long time ago.

Top

attila

Post subject: Re: OpenGL ES Port

Posted: 10.06.2010, 21:33

Joined: 26.08.2008, 18:48
Posts: 120

MistaED: I'm also quite interested about your progress, so keep us updated.

I'm still working on an OpenGL ES 1.1 port.
I've created a fixed function "shader extension". I've attached a very brief documentation about it. (ff_shader.txt)
The corresponding API is very similar to the OpenGL API with some simplification/modification. (oglExtensions.h)
The implementation is still missing functionality and probably has lots of bugs, so I don't share it yet.
I'm using some code from Horde3D: Tokenizer and RBObjects. Is there any legal issue with this?

The port in its current state is able to render the knight sample. Uses software skinning. No lighting, reflection map, particle system, overlay though.

I list of problems I encountered. Some of them is shared with OpenGL ES 2.0 (I mark with * the problems that AFAIK exist with ES2.0 too).

- I tried to modify(created an ES11 version for this) only utOpenGL and egRendererBase. The only other
modification I made I replaced the glsl shaders in egRenderer.
- I don't see an easy solution to support particle system rendering with fixed function functionality.
- I've defined empty macros for missing functionality that are used in egRenderer.cpp:
glPolygonMode(*), glDrawBuffers(*), glBegin(*),glEnd(*),glVertex3fv(*), glUniform1xx that are not supported in ffshader,
GL_TEXTURE_WRAP_R, GL_CLAMP_TO_BORDER, GL_TEXTURE_BORDER_COLOR,
GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE, GL_TEXTURE_COMPARE_FUNC,
GL_DEPTH_COMPONENT,GL_QUADS(*),GL_TEXTURE_CUBE_MAP, GL_DEPTH_COMPONENT24,
GL_DEPTH_COMPONENT16
glDrawRangeElements(*) is implemented using glDrawElements.
- in egRendererBase: there is no GetBufferSubData(*) vertex buffer/index cloning. I implemented it storing data in system memory. (cloning was needed for software skinning)
No glGet(Compressed)TexImage(*) for getTextureData.
There are missing functions for renderbuffers. I've just commented these out to work with the default framebuffer.
No Occlusion query support. dummy implementation.
Vertex layout is modified to use fixed function vertex/color/... pointers instead of attrib pointers.

utOpenGLES11 includes the following extensions (for OpenGL ES1.1 and OpenGL 1.5)
EXT_framebuffer_object;
EXT_texture_filter_anisotropic;
EXT_texture_compression_pvrtc;
EXT_texture_compression_s3tc;
OES_framebuffer_object;
The EXT_framebuffer_object and OES_framebuffer_object are very similar, I will probably try to merge the entry points.

Attachments:

oglExtensions.h [2.64 KiB]
Downloaded 1121 times

ff_shader.txt [2.45 KiB]
Downloaded 1115 times

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 11.06.2010, 02:51

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

attila: Sounds very familiar to me on your steps.

So far I have a blank screen and I've just got a test SDL context window up and running that has GL ES2 support running on my N900.

We should definitely combine our developments as the ES 1.1 fixed-function mode sounds great. Are you planning to optimise software skinning with VFP or NEON?

From reading what you've done, it looks like your approaches look a little more elegant than mine, I would really like to see your changes for egRenderer and egRendererBase, especially how you got around the lack of glGetBufferSubData. But like I sort of implied before, I'm just learning how things work internally and I have most likely done some silly things.

Changes so far for me:

utOpenGL.h pretty much contains gl2.h + gl2ext.h headers, and utOpenGL.cpp still checks for available extensions but they're tailored to ES 2.0 extension detection.

egRenderBase is a war-zone of commented-out parts and re-implementations, a real mess, but RGB565,RGB555_A1 & RGB4 support is in the TextureFormats system now. Float textures are commented out for now, but I think I saw an extension for these so I'll put them back in once I've added in the right detection. PVRTC support is in but needs testing after I get at least something to render. GL_DEPTH_COMPONENT16 & GL_DEPTH_COMPONENT24_OES get detected from the extensions list, but I was reading that the drivers don't have depth_texture support so I'll need to test out a solution for that. Framebuffers are just assumed now so no checking and I omitted the EXT.

egRenderer, I think it was mostly commenting out deprecated stuff like some glTexParameteri calls and all occlusion queries are disabled except for frustum checking, but I take it that the tile-based deferred renderer will handle the grunt work here internally as long as discard glsl code is run in a separate pass to the main one but that shouldn't be too hard to setup in the pipeline. Debug draw is completely commented out.

egTexture: added an else if between the dds and stbi loader code for pvr detection and loading, which is based loosely on the dds detection/loading and what I saw in the powervr SDK and oolong engine detection.

Volker: Thanks for the offer however I don't really feel too confident in my efforts for others to look at.

Not yet anyway, but I will post my changes once they work.

Thanks all

_________________
-Alex
Website

Top

attila

Post subject: Re: OpenGL ES Port

Posted: 12.06.2010, 13:45

Joined: 26.08.2008, 18:48
Posts: 120

The fixed function shader works pretty well now. The only thing it needs is proper error handling and probably some bugfixing.

I haven't planned to optimise the software skinning but it is a good idea.

To be honest my implementation is still a little messy and incomplete. I've tried to modify the egRendererBase and utOpenGL only.

egRenderer: I didn't do anything interesting. Just removed the #include "utOpenGLES.h" and replaced two shaders (vsDefColor, fsDefColor) implementation with fixed function version.
To get it compiled I've put some #define to egRendererBaseOpenGLES11.h like

Code:

#define glBegin(a) do{}while(0)

.

in utOpenGLES11: I followed the method that horde3d used. so I modified the original file. removed non es11 compatible functions/macros and added es11 ones.

egRendererBase: To workaround that there is no glGetBufferSubData I've just stored the data in RBBuffer. It is not a great solution as this doubles the memory usage for meshes. I've found that there is GL_OES_mapbuffer, but that is for writeonly access too. I've seen some benchmark on the net, and it seems that there was no real performance advantage using buffers, so just using plain sytem memory data would be an option too. (at least for some platforms).

I've planned to do pvrtc support, but would like to use yours as you are ahead of me in texture support.

For easily maintanable platform support I think it would be best to use the least platformdependent file possible. utPlatform(ES11) files should be pretty stable so not too many maintainance work with it. It would be great if any other difference would be in egRendererBase only.
Pvrtc: I know that horde3d is for simplicity but an added pvrtc support for the main branch wouldn't add too much code. Pvrtc support is very common on mobile devices.

I will share my sources. But I would like to solve some issues i know of.

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 13.06.2010, 15:36

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

Ok, I've got some silly workarounds in place, and I've learned a hell of a lot on GLSL shaders and can appreciate the FX shader linking system horde has.

Although having said that, for some reason you can't have lengthy function calls with a lot of arguments so I had to convert it so some of the code is compiled without functions. So now for example FS lighting in model.shader now has calcPhongSpotLight removed and now it just has the code from there on the end (really weird but whatever!).

Anyway the ones which contribute to the forward renderer all compile fine, and the deferred render related ones all fail because they're looking for multiple buffers which aren't there naturally.

attila: for glGetBufferSubData did you just comment out the function entirely in favour of this solution in egGeometry?

http://pastebin.com/pMqkSBSF

I've read over it but I have no idea if that's a real fix, probably self-explanatory but just in case: the commented out part has what was there and the //workaround parts are the lines I added.

Everything seems to be loading and rendering fine from what I see by putting many print functions everywhere, however my screen is completely blank and I have no idea why. I might be doing something dumb on the SDL context-creation so I'll do another check on that. QtCreator + Maemo support doesn't have gdb working yet, hope they fix that soon.

Thanks guys

_________________
-Alex
Website

Top

attila

Post subject: Re: OpenGL ES Port

Posted: 13.06.2010, 20:12

Joined: 26.08.2008, 18:48
Posts: 120

I've solved the issue of missing glGetBufferSubData differently, but your solution seems to be better, as the vertex data is already stored in egGeometry. I've tried your patch and it seems to work well.
Right now, I don't see the point in using cloneBuffer in that function. CloneBuffer is used only there so if there are no further plans for using it elsewhere, we can get rid off that completely. ???

It is not an easy task to get something rendered on screen when porting an engine, because many things can go wrong.
I would first check that if at least the rendertarget, viewport is set up properly. Try to clear the rendertarget with non-black color for example(in the pipeline).
Checking glGetError is also a good idea.

Hope it will work soon, keep up the good work

Top

MistaED

Post subject: Re: OpenGL ES Port

Posted: 14.06.2010, 07:12

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia

You legend! I checked the pipeline and decided to clear it with completely red.

I think it is how the ambient term is being derived. I need to figure out how to do pvr texture loading as well as cube maps from them. I'll get to work on this right now! Works on the Horde_Qt and my own SDL code now.

Attachments:

File comment: Victory-ish!

Screenshot-20100614-160946.png [ 19.07 KiB | Viewed 32026 times ]

_________________
-Alex
Website

Top

Page 3 of 11

[ 154 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6 ... 11 Next

Board index » Horde3D Development » Developer Discussion

All times are UTC + 1 hour

Who is online

Users browsing this forum: No registered users and 60 guests

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