3

This is related to OpenGL ES 2.0 :glReadPixels() with float or half_float textures.

I want to read out the float values from a framebuffer object after rendering.

On iOS, the following 

    GLint ext_type;
    glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_TYPE, &ext_type);

really just tells us that glReadPixels only allows GL_UNSIGNED_BYTEs to be read out.

Is there a way to use the textured cache technique related in this article to get around this?

The back story is that I am trying to implement a general matrix multiplication routine for arbitrary-sized matrices (e.g., 100,000 x 100,000) using an OpenGL ES 2.0 fragment shader (similar to Dominik Göddeke's trusty ol' tutorial example). glReadPixel is not being particularly cooperative here because it converts the framebuffer floats to GL_UNSIGNED_BITS, causing a loss of precision.

Community
  • 1
  • 1
cklin
  • 900
  • 4
  • 16
  • It's quite likely you will never reach more than 2048x2048 matrices since that's the texture size limit. Going beyond that would require multiple textures and multiplying two 2048x2048 matrices is going to feed up the fragment shader with thousands of texture lookups per pixel already. – harism Jan 11 '13 at 23:45
  • @harism Do you have any feel for the lookup performance? I'm not familiar w/ the GPUs on iOS devices. How limited is the bandwidth in practice? I was guessing it's possible to render large textures in say 200ms? – cklin Jan 12 '13 at 00:02
  • Unfortunately I do not hold Apple developer license and never had a chance to try out the limits of my iOS devices myself. But after doing some GPGPU on OSX/OpenGL 3.2 I'm afraid ES will choke already at rather small matrices. – harism Jan 12 '13 at 00:10
  • @harism - You're right, texture lookups tend to be extremely expensive on the iOS GPUs. Performing up to 8 non-dependent texture reads in a single fragment shader is very fast, but anything beyond that triggers a dependent texture read on most iOS devices. When you start adding on more texture reads than that, performance drops through the floor. At about 80+ texture reads per fragment, you'd almost be better off running these operations on the CPU, particularly if you were to use the Accelerate framework. – Brad Larson Jan 12 '13 at 22:09
  • @BradLarson - I'm pretty new to GPGPU and iOS -- could you please elaborate a bit about why dependent texture reads would be triggered? And do you have any sense for the time it takes for a texture lookup on say an iPad 3? Thanks! – cklin Jan 13 '13 at 02:21
  • 1
    @cklin - A dependent texture read is normally triggered when the texture coordinate used for the read is calculated within the fragment shader. If you can, move that calculation up to the vertex shader. However, past a certain point on iOS devices (as low as 8 reads in a fragment shader), all texture reads are dependent ones. Note that I'm talking about texture reads per fragment here, because you could be dealing with a million+ fragments per rendered scene. An iPhone 4S can process a 1080p frame (2 MP) with 9 non-dependent reads per fragment in ~14 ms. – Brad Larson Jan 13 '13 at 03:20

1 Answers1

1

I asked a similar question and I think the answer is NO, if only because texture caches (as an API) use CoreVideo pixel buffers and they don't currently don't support float formats.

Community
  • 1
  • 1
Rhythmic Fistman
  • 34,352
  • 5
  • 87
  • 159