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
