On 04/25/2011 04:36 PM, Tristan Schmelcher wrote:
On 25 April 2011 16:22, Ian Romanick<i...@freedesktop.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/25/2011 04:15 PM, Tristan Schmelcher wrote:
I have an OpenGL app where I'm writing video frames to textures. The
video frames are semantically opaque but the alpha in the source
pixels is set to 0xff, so I have been using glTexImage2D with
format=GL_RGBA and internalFormat=GL_RGB to indicate that the input
has a valid alpha channel but that the OpenGL implementation could
discard it if it wanted to (e.g., if the hardware had native support
for GL_RGB which was faster than its GL_RGBA support, or something).
I can't imagine that ever happening for 8-bit per component color. RGB
with 8-bits per component is 3 bytes, so drivers will always promote
this to RGBx (a single byte of unused padding). This is basically what
you already have.
Yeah, I am definitely going to change my code to use GL_RGBA to fix
things ... I'm just puzzled about why the perf is so bad on this
system when using GL_RGB. My app has been used on a lot of other
systems (with many different OpenGL implementations) and this is the
first time I've seen this problem.
This has worked well for me on most systems, but today I found that it
results in poor glTexSubImage2D() performance on an Intel IGDNG_M GPU
(i965-based) with MESA 7.7.1 (using Ubuntu Lucid). Because
internalFormat is GL_RGB instead of GL_RGBA, _mesa_texstore_argb8888
takes a slow path by using _mesa_swizzle_ubyte_image instead of
memcpy_texture.
If you have a debug build of Mesa, you could try running your app with
INTEL_DEBUG=fall set. That should print out warnings if you hit any
software fallbacks in our driver. They should be very rare, but would
cause a performance cliff.
I know that I fixed a software fallback when doing glCopyTexImage from
ARGB8888 to XRGB8888 in master last month. Not sure if it's relevant.
As Ian mentions, a lot has changed since 7.7. Even if that one function
hasn't changed much, it would still be worth a try.
--Kenneth
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
