Re: Optimization idea: soft XvPutImage
--- On Mon, 9/22/08, Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2008-09-21 at 13:58 +0200, Soeren Sandmann wrote: As other people pointed out, XRender does allow arbitrary 3x3 transformations of source images, but you are right that the XRender protocol would require putting the data in a drawable first. There could be a generic XVideo adaptor which uses RENDER internally. The Xgl code might already have something like that. Wow! Right you are. xorg-server-1.5/src/hw/xgl/xglxv.c. At first glance, at least, it looks like it should be readily portable for Xgl to fb, as the Xgl specific stuff appears to be contained mostly in well labelled macros. Thank you very much for pointing this out. Adam Richter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Optimization idea: soft XvPutImage
On Fri, 9/19/08, Soeren Sandmann [EMAIL PROTECTED] wrote: Adam Richter [EMAIL PROTECTED] writes: I want to suggest a way we could eliminate a substantial amount of data copying [...] [...] Pixman, the software implementation of XRender already has support for YUV formats, so all that is really required is to just export YUV picture formats through the XRender protocol. [...] Thank you for pointing out that pixman has some limited YUV reading support already. The biggest problem that I see with using the X Render is that it lacks stretch and shrink, at least if I understand correctly from looking at the protocol specification here: http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt See lines 758-766: Composite op: PICTOP src:PICTURE mask: PICTURE or None dst:PICTURE src-x, src-y: INT16 mask-x, mask-y: INT16 dst-x, dst-y: INT16 width, height: CARD16 The last two parameters (width and height) presumably apply to both source and destination rather than having separate parameters for the source and destination rectangles. This also appears to be the case when I look in the header for the pixman library (pixman-0.12/pixman/pixman.h) at the declaration of pixman_blt. It also only has a width and height, which presumably apply to both source and destination. Even if you do not want to do stretch, I believe that the X Render extension would require first copying the YUV data to a drawable and then doing a drawable-drawable block transfer operation to do the YUV transformation. In comparison, XvPutImage is a single call takes an XImage, which can be in shared memory, and would normally be in YUV, and specifies the YUV-RGB conversion and stretch in a single operation. Thanks for your input, especially the tip about some YUV support already existing in libpixman. Adam Richter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Optimization idea: soft XvPutImage
, 3D surely will provide better performance than any software XvPutImage, and there is apparently already support for this in at least one video player. Alternative #2: I do not know enough about DRI to be sure about this, but I think that a slightly more optimal approach for systems without any hardware video acceleration would be to allow trusted (i.e., privileged) video players to map the frame buffer directly and coordinate changes to clip regions and window coordinates, which I think is done already done for 3D using the Direct Rendering Infrastructure (DRI). As far as I know, DRI theoretically does not actually require 3D, video players with appropriate permissions should be able to use DRI to map the frame buffer and draw to it. However, DRI currently requires a DRM driver for each type of video card, and this would require writing new (but relatively simple) video output drivers any video player that would use this approach, whereas Soft XvPutImage should work with existing video players that already support Xv. There are also the relatively minor drawbacks of this approach being limited to the very common case of the player running on the same machine as the frame buffer, the frame buffer being memory mapped in a sensible format, and the video player running with enough privilege to use DRI. I have written this description partly so that I will no longer feel like a roadblock to more ubiquitous video playing by not mentioning it and not getting around to implementing it, and also to find out if there are compelling reasons not to do it, such as an existing implementation that I have missed or an already existing optimization in software video playing that makes this optimization idea useless. So, further analysis, corrections, and, of course, implementation, would be most welcome. Adam Richter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
