glReadPixels - is it really THIS slow....
Mendel Kucharzeck
I am using glReadPixels to determine if an pixel is occluded by something or
not. It works but it is really slow. I know that the graphics card (Radeon
8500 in a Apple G4 in my case) has to wait till the poly-queue is empty
before reading the pixel but this is not the problem. If I execute
glReadPixels 20 times it needs the same time for every run of the function!
IF glReadPixels is waiting for the completition of some triangle calls it
should wait once with the first call and then the queue is empty!
I am calling :
glReadPixels(x,y,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&ret);
Please help me!
Mendel.
--
www.xcene.com
Ruslan Abdikeev
news:B93926A5.29CBD%avisno...@t-online.de...
Yes, glReadPixels() is a VERY slow.
But do you think GL_FLOAT is exactly what you want?
I suspect that depth values are actually stored in some 24:8 or 32:0
integer (or fixed point) representation, so you also request
some heavy reconversion of depth buffer.
One way is to use standard form
glReadPixels(...., GL_DEPTH_COMPONENT, GL_INT, ... );
It is standard, I think you can use it, but I cannot promise you'll buy too much.
On nVidia cards, there is NV_packed_depth_stencil extension, which
allows to explicitly select appropriate format, e.g.
glReadPixels(...., GL_DEPTH_COMPONENT, GL_UNSIGNED_INT_24_8_NV, ... );
Hope it helps,
Ruslan Abdikeev
Ruslan Abdikeev
news:B93926A5.29CBD%avisno...@t-online.de...
>
> I am using glReadPixels to determine if an pixel is occluded by something or
> not. It works but it is really slow. I know that the graphics card (Radeon
> 8500 in a Apple G4 in my case) has to wait till the poly-queue is empty
> before reading the pixel but this is not the problem. If I execute
> glReadPixels 20 times it needs the same time for every run of the function!
> IF glReadPixels is waiting for the completition of some triangle calls it
> should wait once with the first call and then the queue is empty!
>
Oh, just forgot to add: nVidia cards support NV_occlusion_query and
HP_occlusion_test extensions, which allow you to test occlusion
efficiently enough.
However, I haven't seen them on ATI cards.
Ruslan Abdikeev
Ruud van Gaal
<rus...@vr1.spb.ru> wrote:
>"Mendel Kucharzeck" <avisno...@t-online.de> wrote in message
>news:B93926A5.29CBD%avisno...@t-online.de...
>>
>> I am using glReadPixels to determine if an pixel is occluded by something or
>> not. It works but it is really slow. I know that the graphics card (Radeon
>> 8500 in a Apple G4 in my case) has to wait till the poly-queue is empty
>> before reading the pixel but this is not the problem. If I execute
>> glReadPixels 20 times it needs the same time for every run of the function!
>> IF glReadPixels is waiting for the completition of some triangle calls it
>> should wait once with the first call and then the queue is empty!
>>
>> I am calling :
>>
>> glReadPixels(x,y,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&ret);
>>
>
>Yes, glReadPixels() is a VERY slow.
>But do you think GL_FLOAT is exactly what you want?
>I suspect that depth values are actually stored in some 24:8 or 32:0
>integer (or fixed point) representation, so you also request
>some heavy reconversion of depth buffer.
For ONE pixel the 'heavy' conversion should be doable about a zillion
times/sec.
Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art : http://www.marketgraph.nl/gallery/
Mendel Kucharzeck
> "Mendel Kucharzeck" <avisno...@t-online.de> wrote in message
> news:B93926A5.29CBD%avisno...@t-online.de...
>>
>> I am using glReadPixels to determine if an pixel is occluded by something or
>> not. It works but it is really slow. I know that the graphics card (Radeon
>> 8500 in a Apple G4 in my case) has to wait till the poly-queue is empty
>> before reading the pixel but this is not the problem. If I execute
>> glReadPixels 20 times it needs the same time for every run of the function!
>> IF glReadPixels is waiting for the completition of some triangle calls it
>> should wait once with the first call and then the queue is empty!
>>
>> I am calling :
>>
>> glReadPixels(x,y,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&ret);
>>
>
> Yes, glReadPixels() is a VERY slow.
> But do you think GL_FLOAT is exactly what you want?
> I suspect that depth values are actually stored in some 24:8 or 32:0
> integer (or fixed point) representation, so you also request
> some heavy reconversion of depth buffer.
>
> One way is to use standard form
> glReadPixels(...., GL_DEPTH_COMPONENT, GL_INT, ... );
> It is standard, I think you can use it, but I cannot promise you'll buy too
> much.
>
Thanks for your answer!
I tried GL_INT instead of GL_FLOAT, there is absolutly no difference! damn.
I am executing 2 calls to glReadPixels and 50% of the time is spent in these
calls. I am drawing an terrain using triangle strips und some objects and
two flares.
Why is this so slow? It is not waiting for something to excecute...it cant
take 50ms to transfer 16 or 32 bits over the agp.....what is so time
consuming?
Thanks again,
Mendel.
--
www.xcene.com
Ruslan Abdikeev
> > "Mendel Kucharzeck" <avisno...@t-online.de> wrote in message
> > news:B93926A5.29CBD%avisno...@t-online.de...
> >>
> >> glReadPixels(x,y,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&ret);
> >>
> >
> > Yes, glReadPixels() is a VERY slow.
> >
>
> I am executing 2 calls to glReadPixels and 50% of the time is spent in these
> calls. I am drawing an terrain using triangle strips und some objects and
> two flares.
>
> Why is this so slow? It is not waiting for something to excecute...it cant
> take 50ms to transfer 16 or 32 bits over the agp.....what is so time
> consuming?
>
I haven't noticed that you are reading ONE pixel, my apologies.
It's strange, as I used to call glReadPixels() to fade sun flares,
and it worked amazingly fast.
Ruslan Abdikeev
Ruslan Abdikeev
> On Fri, 21 Jun 2002 21:13:18 +0400, "Ruslan Abdikeev"
> <rus...@vr1.spb.ru> wrote:
> >"Mendel Kucharzeck" <avisno...@t-online.de> wrote in message
> >news:B93926A5.29CBD%avisno...@t-online.de...
> >>
> >>
> >> glReadPixels(x,y,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&ret);
> >>
> >
> >Yes, glReadPixels() is a VERY slow.
> >But do you think GL_FLOAT is exactly what you want?
> >I suspect that depth values are actually stored in some 24:8 or 32:0
> >integer (or fixed point) representation, so you also request
> >some heavy reconversion of depth buffer.
>
> For ONE pixel the 'heavy' conversion should be doable about a zillion
> times/sec.
>
Oh, my apologies.
Didn't draw attention to that "1,1" thingy...
So do you have any ideas?
Ruslan Abdikeev
Ruud van Gaal
I'm doing the exact same thing; draw objects, read 1 pixel, and if
Z!=clearZ then the sun is hidden. Doesn't seem to slow things down
here.
Are you sure (Mendel) that no pixel transfer peculiarities are set
(bias/scale)?
One other thing *might* be that x/y are invalid? (glRasterPos())
Mendel Kucharzeck
> Z!=clearZ then the sun is hidden. Doesn't seem to slow things down
> here.
>
> Are you sure (Mendel) that no pixel transfer peculiarities are set
> (bias/scale)?
The frame impact is so huge like I transfer the whole depth buffer with
glReadPixels! but I only transfer 1 pixel!
>
> One other thing *might* be that x/y are invalid? (glRasterPos())
(fullscreen) is 1600x1200, glOrtho2d is set to 1024x768 and I am sure I am
converting correctly because it is working!
I will try it on a Win32 machine tomorrow to see if it is a MacOS X OpenGL
issue (will not be the first ;) )
Thanks for your help, I hope we can figure it out because I need the code to
work!
Mendel.
Mendel Kucharzeck
I encountered another weired issue with glReadPixels : I am using it to read
1 pixel but the performance is resolution-dependent!! If I read a pixel from
the depth buffer at 640x480 it is faster than in 1600x1200!
What could cause this behaviour? Does GL copy the whole depth buffer over
the agp just to access one pixel?
Thanks,
Mendel.
Ruud van Gaal
Hm, Mac OS-X? Hm, sure sounds like it is, indeed. I'll remember that
if/when I port my game to Mac.
Ofcourse, this can almost be considered as a bug; it's grossly
inefficient.
Wolfgang Draxinger
> I'm doing the exact same thing; draw objects, read 1 pixel, and if
> Z!=clearZ then the sun is hidden. Doesn't seem to slow things down
> here.
Do you have any idea, how to achieve this effect without glReadPixels?
And is there some solution, that allows me to get some alpha value from
that pixel e.g. if I'd like to depend the strength of the lens flare by
cloud occlusion or something similair or making flares also with
transparent things between?
Mendel Kucharzeck
the glReadPixels method (when it works correctly, not like in my case!)
> And is there some solution, that allows me to get some alpha value from
> that pixel e.g. if I'd like to depend the strength of the lens flare by
> cloud occlusion or something similair or making flares also with
> transparent things between?
With glReadPixels : no. This is depth information, the depth buffer does not
store any information about transparency or something.
With the ray-casting method it should be easy because you know where the ray
passes the triangle and what texel you are hitting.
Mendel.
--
www.xcene.com
Wolfgang Draxinger
I already found a practicable solution using pbuffer:
If the sun is visible I redraw the transparent polys of the scene into
pbuffer using the same ALPHA and black as drawing color, background is
1.0. Then I read out the same pixel again and use it's value for the
lens flare, simple isn't it? :-)