about new intel driver (mode-setting branch?)

[leon zadorin]

a couple of questions re. new (> v2) intel driver (and its Xvideo
support) from a nubie...

firstly, there appears to be a limit at "downsizing" of a given
image... i.e. if an original image is being rendered onto a drawable
(window) via XvShmPutImage at a smaller size, then (whet size gets
smallish) the resulting (drawn) image is rather not properly displayed
(usually, only a very small, top left corner section of the original
image is displayed in a magnified state)...

Originally, I didn't think that the problem was that bad - I am
writing a video streaming app and it basically has 2 ways to show a
video/images: in a "thumbnail" and in a fully expanded, resizeable
window and it is the "thumbnail" that was concerning me...

Now, if there was a simple "dimensions" limit as to how small of an
image the driver is capable of rendering, then all I would have to do
is change the thumbnail's windows size to be a bit bigger - no problem
there...

Unfortunately, the limit in "downsizing" is not at a fixed dimension
but depends on the original image's size (which makes a lot of sense
actually)... in other words, if original image is say 720x576 then the
minimum display dimensions that I could achieve would be ~ 103x83...
yet if the original image was smaller (e.g. 352x288) then the minimum
display dimensions for that image would also me smaller (i.e. less
that 103x83)... (commercial nvidia driver, on the other hand does not
exhibit these problems - at least not in the range of ~50x50 display
dimensions for either DV or HDV image sizes)...

Technically, I could just ballpark for the largest image that my app
would process (e.g. HDV) and then make my thumbnails (which, according
to GUI layout, should be of the same size for all video streams being
processed by the app - it is a video multicasting tool so multiple
streams on the same address are expected) to be of the smallest
intel-renderable size... but... given that the original thumbnail size
(which users are accustomed to and which works fine with nvidia
(albeit commercial) drivers) is 80x60 and that minimum
intel-renderable DV size is 103x83... I don't think that making all
thumbnails to be at minimum for HDV would be acceptible (which I
expect would be even > 103x83)...

Ideally, (although may be it depends on the intel's GPU chip) it would
be nice to find out if this downsizing limit thingy is "as per design"
of the new driver or is it a bug?

Second question is this:
Given the source image's data of planar yuv format (I420 FOURCC), and
say display's format in RGB 24bbp... will the colorpsace conversion be
done by hardware or by the driver in software?

Third question is for scaling: is that done in hardware or software?

In case that the answers to all of the above questions are dependant
on the chip version of the intel's GPU - is it possible to get some
info as to which chips do what in hardware and what in software?

Running on my current test machine, each of the DV stream rendering
does take quite a bit more CPU (as per top's output for Xorg) than
nvidia's box... (and of course - no 3D in my app - just plain 2D
scaled images almost exclusively in I420 format)

Attached is the log output of xorg server...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 43534 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070522/cd83453a/attachment.bin>