On Mon, Oct 12, 2009 at 11:58 AM, José Fonseca <jfons...@vmware.com> wrote: > Younes, > > I've finally took a good look to your changes. Again, I don't know > enough about video to comment on the details, so comments below focus > more on shape than the content. > > Overall the interfaces look sane to me. The point I'm a bit skeptical > about is your choice above of pipe_video_surface over pipe_surface and > pipe_texture. I don't see a reason for video frames to be handled > differently -- even if the pixel formats that can be used by > pipe_context and pipe_video_context are disjoint the resource management > side of it can still be shared.
Thanks for the comments. Originally I had pipe_texture used in place of pipe_video_surface, but I assumed people who weren't interested in video wouldn't want to deal with textures that weren't really always textures as far as pipe_context was concerned. As it stands, aside from pipe_screen::video_surface_create() the rest of the video interface doesn't really mess with the 3D bits so it's not too much of a burden on anyone and can be ignored easily enough. Originally I noticed that pipe_format doesn't describe any kind of planar formats, which are far more common in video. However it looks like PIPE_LAYOUT_YCBCR only uses 2+3 bits so there's actually a lot of room left there to describe the planar/interleaved/packed, etc layouts that are common in video. It's not too much trouble to change, and it does allow for uploading of pre-decoded frames via pipe_transfer for things like Xv so I'd go with that. > Furthermore, we've been considering unifying pipe_textures it with > pipe_buffers, making pipe_surface/texture/buffer mere views of a > "pipe_resource". There are some OpenGL extensions that would become > easier to implement if this was the case, and this is also aligned with > the DirectX10 does. So adding yet another resource type put us another > step back on this direction. > > Also, why is pipe_mpeg12_macroblock::blocks a void * and not a > pipe_buffer *? Won't that data ever be touched by the hardware? Oversight. That struct is mostly 1:1 with XvMC's macroblock definition. The blocks may or may not be touched by the hardware directly so a pipe_user_buffer seems logical here. > Finally, u_reduce_video_profile() should be in auxiliary/util. We want > to move towards having only interfaces in include/pipe, and move inline > helpers to auxiliary/util. It's messy change so there has been inertia > in making it happen, but new code should try to stick with this. Will do. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
