HI
I copy the colorbuffer of a pbuffer to a texture.
The texture had the internal format of RGBA8 and the framebuffer is the same format. I tought that there should be no conversion. Buts its really slow. It’s the nvidia linux 66.29. I really have no clue that could be wrong.
tnx, marco
Originally posted by ZbuffeR:
Looks like the problem I describe (and solve) here :
http://www.chez.com/dedebuffer/
That can’t be because its also very slow if I copy from the backbuffer. Also there is no render to texture extension under linux. As far a I know Doom 3 is using this function so this must be my fault. I really have no clue.
I have changed the internal format to
RGBA_FLOAT16_ATI and the pbuffer to the same sizes but its very slow too. I can’t see whats wrong.
Maybe you are right. I have changed some setting and its fast with the backbuffer but slow with the pbuffer. My settings are not special:
attribs[0] = GLX_DOUBLEBUFFER
attribs[1] = double_buffer
attribs[2] = GLX_RED_SIZE
attribs[3] = red_size
attribs[4] = GLX_GREEN_SIZE
attribs[5] = green_size
attribs[6] = GLX_BLUE_SIZE
attribs[7] = blue_size
attribs[8] = GLX_ALPHA_SIZE
attribs[9] = alpha_size
attribs[10] = GLX_DRAWABLE_TYPE
attribs[11] = GLX_PBUFFER_BIT
attribs[12] = GLX_FLOAT_COMPONENTS_NV
attribs[13] = float_buffer
attribs[14] = 0
I don’t know what is happen. Maybe its a driver bug.
Maybe your settings are not special, but what are the actual values ?
I suppose you already did it, but try removing everything, then adding only some params etc.
It may well be a driver bug anyway.
Since you’re copying something that Doom3 does, and that it is fast for them but slow for you, you may have to consider that the driver is detecting Doom3 and doing its copy texture operation in a special way. A way that other applications can’t get access to.
I’m not saying that you should stop looking for the problem. But it is something that you may have to consider.
GLX_FLOAT_COMPONENTS_NV
Doesn’t that make the pbuffer a floating point buffer? Which presumably makes the buffer relatively large (as compared to a normal RGBA8 buffer - 4x the data?) And a float buffer is not RGBA8 (as far as I know) - which would mean data conversion during the copy.
Is it valid on NV hardware to use an internal format of RGBA_FLOAT16_ATI? (Just curious, I haven’t looked at float buffers).
What if your pbuffer were not setup to be a float buffer? Set it up as a plain RGBA8 buffer and see what difference it makes.
Originally posted by rgpc:
[quote]GLX_FLOAT_COMPONENTS_NV
What if your pbuffer were not setup to be a float buffer? Set it up as a plain RGBA8 buffer and see what difference it makes.[/QUOTE]No, there are no differences. I use a float texture too. Its no difference. The problem ist the copy from the pbuffer to the texture.
Is there a Linux equivalent to ShareLists()? If so, have you called it? (I had a look in my Red book and couldn’t spot anything that looked like ShareLists)
Originally posted by rgpc:
Is there a Linux equivalent to ShareLists()? If so, have you called it? (I had a look in my Red book and couldn’t spot anything that looked like ShareLists)
The lists, objects are shared, you say it in the context creation. glXCreateNewContext last argument is the context to share. I don’t know how its handled under wgl, haven’t used windows since 10 years.