Yes same thing is happening for me.

I have also written program in opengles 2.0 and uploading texture yuv
is taking around 54ms and rendering is taking 20 ms.

640*480.

But what i feel is this is blocking cpu but i dont know how to do all
of that in gpu or second option is that all this is happening in
software.

regards,
Niral

On Nov 5, 12:57 am, 袁堂夫 <yuantangf...@gmail.com> wrote:
> thanks for your response, yes, our frame is from a live camera, so it
> changes dynamically.
> as what you said, we passed YUV frame to the GPU, and do the YUV to
> RGB convert in the GPU side (we used matrix-vector multiplication).
>
> My questions are:
> 1) Does the GPU convert blocks the CPU?
> 2) if the first answer is "no", then why transmit a 600*300 image from
> CPU to GPU caused about 40ms in the nexus one (1G CPU)? we used
> glTexImage2D to pass the Y,U,V data to the GPU.
>
> 2010/11/4 ChrisAR <chri...@chrisar.me>:
>
>
>
>
>
>
>
> > I need a little bit more of information before I can answer this
> > properly. Is your raw YUV frame being passed to the GPU as an OpenGL
> > ES texture? Is this YUV frame a static image, or it changes
> > dynamically (like, is it being captured from a live videocamera in
> > real time)?
>
> > Doing the math to (a) properly scale your data ([0...256] to
> > [0.0...1.0], or whatever range you need) is trivial, then (b)
> > converting from YUV to RGB is simple enough (http://en.wikipedia.org/
> > wiki/Yuv#Converting_between_Y.27UV_and_RGB), and then fitting the
> > result into an appropriate OpenGL texture format is easy.
>
> > The decision you need to make is when you will perform this math. If
> > it is a static frame (it doesn't change frequently), you can just do
> > it in the CPU; this is the easy case.The tricky part is if your YUV is
> > supposed to change frequently. If this is the case, then:
> > -If your demo is in OpenGL ES 2.0, this is not too bad. You could
> > update the OpenGL texture with your new YUV frame, and then use a GLSL
> > ES fragment shader to do the math. You will need to be careful so it
> > is optimized. Keep in mind that most OpenGL ES 2.0 mobile GPUs out
> > there aren't very friendly to fragment-shader-intensive operations in
> > terms of performance. I have done this in the past, and it is not hard
> > to do at all (just a matrix-vector multiplication!)
> > -If your demo is in OpenGL ES 1.x, or if your fragment shader is too
> > slow, then you should look into optimizing your CPU conversion.
> > Possibly look at ARM NEON extensions and see if that would speed your
> > math (if your platform supports NEON, since not all ARM licensees have
> > it).
>
> > On Nov 3, 10:26 pm, 袁堂夫 <yuantangf...@gmail.com> wrote:
> >> I think the FBO does not surppot  YUV format texture,so do you have
> >> some good idea?
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to