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
