Raspberry Pi - Failed to link vertex shader and pixel shader: Too many uniform values

[weitjong]

I have attempted to port Urho3D engine to Raspberry Pi. I have patched the code enough to make the engine compile and run in Raspberry Pi. At first I have compiled it against Mesa OpenGLES implementation for X. I don't even need to touch the code in SDL for this to work. NinjaSnowWar demo runs with keyboard/mouse input, audio output, and AngelScript, seems to be working correctly. Although all the shaders compiled and linked correctly, the rendering output quality is, however, quite disappointing and only achieves 1 to 2 FPS :(

I have later found out that currently Mesa/X implementation is not hardware accelerated. So, my second attempt is to hack the SDL code to interface with Broadcom VideoCore GPU directly. However, I still have a few runtime issues with my second attempt. One of them is failure to link the VS and PS programs: Too many uniform values. Even the Basic shader does not link. Any idea how to resolve this?

BTW, I am using Pidora (Fedora Remix optimized for Raspberry Pi).

[Chris Friesen]

this stuff is out of my league but here is the source code for quake 3.  https://github.com/raspberrypi/quake3/tree/master/code/renderer

i would be willing to test things.  i have a pi with raspian.

[weitjong]

Thanks for your reply. When I said hacking SDL to interface with VideoCore, what I really meant was changing the SDL code to use the GLES implementation provided by Raspberry Pi that has hardware acceleration support. It is still OpenGLES 2.0.

I am aware of quake3 port project you mentioned. I have planned to look into it closer after I am done. My plan is to see how it configure its build environment for cross-compilating. Currently I am still building from the Raspberry Pi natively, which is slow.

I will check in my changes into Urho3D SVN trunk when it is ready.

[weitjong]

Further update. I have made a little progress on this. I figured out that the OpenGLES 2.0 implementation from the Raspberry Pi firmware has these implementation limits:

EGL

  Vendor: Broadcom

  Version: 1.4

  Client APIs: OpenGL_ES OpenVG

  Extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_vg_parent_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_lock_surface 

OpenGL ES

  Vendor: Broadcom

  Renderer: VideoCore IV HW

  Version: OpenGL ES 2.0

  GLSL version: OpenGL ES GLSL ES 1.00

  Extensions: GL_OES_compressed_ETC1_RGB8_texture GL_OES_compressed_paletted_texture GL_OES_texture_npot GL_OES_depth24 GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_EGL_image_external GL_EXT_discard_framebuffer GL_OES_rgb8_rgba8 GL_OES_depth32 GL_OES_mapbuffer GL_EXT_texture_format_BGRA8888 GL_APPLE_rgb_422 GL_EXT_debug_marker 

  Implementation limits:

    GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS = 8

    GL_MAX_CUBE_MAP_TEXTURE_SIZE = 2048

    GL_MAX_FRAGMENT_UNIFORM_VECTORS = 136

    GL_MAX_RENDERBUFFER_SIZE = 2048

    GL_MAX_TEXTURE_IMAGE_UNITS = 8

    GL_MAX_TEXTURE_SIZE = 2048

    GL_MAX_VARYING_VECTORS = 8

    GL_MAX_VERTEX_ATTRIBS = 8

    GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 8

    GL_MAX_VERTEX_UNIFORM_VECTORS = 136

    GL_MAX_VIEWPORT_DIMS = 2048, 2048

Looking at our Urho3D Uniforms.vert file, surely enough, it exceeds those limits. I then add a directive for the skin matrixes as so.

#ifdef SKINNED

uniform vec4 cSkinMatrices[64*3];

#endif

It solves my Shader linking problem! Except, for the one that uses skinning.

ERROR: Failed to link vertex shader Shaders/GLSL/LitSolid_DirSkinned and pixel shader Shaders/GLSL/LitSolid_DiffAmbientDir:

ERROR:LINK-5 (link time, line -1) Too many uniform valuesglGetError 0x500

[P.B. Noome]

If this is physical limit imposed by the Pi's BCM2835 then either ignore skinning altogether for the Pi or an alternative approach has to be supplied. Wouldn't it be possible to fill a 4-component texture (containing the skin matrices) on the client side and pass that to the shader? Don't know if GLES 2.0 supports texture reads from the vertex shader, but if it does then that might be a solution. The result will be that every 'uniform vec4' is stored in a single pixel.

Can't look at the GLSL code yet and how the matrix is being used\what data it represents, but a trick I've used in the past with (normal) vectors to pack more data in a single RGBA pixel is:

• Normalize vector to unit length, dropping 1 component: XYZ -> XY
  
• (..use freed component for something else..)
• In shader reconstruct XY -> XYZ. The length of Z is: |Z| = 1 - |XY|

Of course, the nature of the data stored should allow for this. For one, you'll lose the sign of Z; but this may or may not be a problem depending.

--
You received this message because you are subscribed to the Google Groups "Urho3D" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urho3d+un...@googlegroups.com.
To post to this group, send email to urh...@googlegroups.com.
Visit this group at http://groups.google.com/group/urho3d.
 
 

[Chris Friesen]

have you seen this article?  it seems that mesa clobbers egl libraries.

http://www.raspberrypi.org/phpBB3/viewtopic.php?p=36318

see if you can link against  the vc folder specifically.  my raspian has a folder for the video core stuff

/opt/vc/include
/opt/vc/lib

[weitjong]

Yes, of course I have. I have researched the related topics over the internet these past few days. This is exactly what I am doing in my second attempt, linking to the OpenGLES 2.0 implementation provided by Raspberry Pi firmware. In Pidora, the library and include folders are slightly different but that's immaterial. Also note that I have progressed beyond the compiling/linking stage. The issues that I am facing right now are mainly runtime issues. The issue with the shader linking problem during runtime can be now considered solved, I think. I have now moved on to other issues.

The good news is, I have setup a cross compiler toolchain using Eclipse :). I hope I am able to progress faster with this new build environment. Thanks again for your reply.

p.s. I think it should be called "Raspbian".

[Alex Fuller]

Hi,

Can't you just limit skinning to something like 32*3 or less and see if it compiles? Surely the ninja model doesn't use up all 64 matrices. I saw that you've passed this issue so I'm guessing you may have tried this already, sweet! :)

It will be great to see it run without X on the Pi, maybe using Wayland+Weston, I think that uses the GPU vendor's GL/EGL directly too.

-Alex

[weitjong]

It is a bug in the first place that uniform only used for skinning is not being declared with proper directive. With that fix, I have no issues with non-skinned shader programs. I could, like you say just for testing, reduce the matrices for skinning and those skinned programs would work too. Having said that, I reckon we don't want to change that permanently in the trunk. Also even if we do work around it using texture/sampler approach as proposed by Paul, we also need to find a way so that the work around is only applicable for Raspberry Pi platform. i.e. the work around should not negatively impacted other supported platforms. I think I will only revisit this again later as I still have a few issues with the port.

My second attempt to link with accelerated OpenGLES was still depend on X. But in my third attempt I try to do it without X. Now I manage to get NinjaSnowWar runs with sound (via ALSA) but not keyboard/mouse input yet (still WIP). The rendering quality and speed is much better now. I am not using Wayland+Weston.