[Spice-devel] Render measurements

Yonit Halperin yhalperi at redhat.com
Tue May 8 01:36:36 PDT 2012


Hi,
Sounds great, the results look promising.

Did you check if there are other operations, besides the "nomask" ones, 
that can be translated to the current QXL_DRAW commands, mainly the 
QXL_DRAW_ROP3 one?

* The number of cached bytes displayed in the spreadsheet is larger when 
caching is off. Mistake on the spreadsheet? Or just difference in the 
websites content?

Cheers,
Yonit.
On 05/07/2012 07:45 PM, Søren Sandmann wrote:
> This branch here:
>
>      http://cgit.freedesktop.org/~sandmann/xf86-video-qxl/log/?h=trackimages
>
> will produce various types of information in the X log file when the
> option "EnableImageStats" is given in xorg.conf. Specifically, it will
> track whenever an operation triggers a fallback and record the number
> of (uncompressed) bytes in the resulting image upload along with a
> reason that the fallback happened.
>
> This repository:
>
>       http://cgit.freedesktop.org/~sandmann/imganalysis/tree/
>
> contains a Python script that will read the resulting X log files and
> do some rudimentary analysis on it. There is also a set of log files
> generated as follows:
>
> cnn.log:
>          - Log in
>          - Open Firefox
>          - Go to www.cnn.com
>
> pinterest.log:
>          - Log in
>          - Open Firefox
>          - Go to pinterest.com
>          - Scroll down for a good while (the site has inifinte scrolling)
>
> oofice.log:
>          - Log in
>          - Open OpenOffice writer
>          - Open this document:
>                 http://www.freedesktop.org/~sandmann/tutorialOOoBase.odt
>                 - Scroll to the end
>
> Each type of log file exists with image caching turned on and
> off. Caching of *fallback* images was turned on in all cases.
>
> The results are available in the attached Gnumeric spreadsheet. The
> main interesting number is 'Estimated saving from Render excluding
> nomask', which is 73% with image caching on and 74% with image caching
> off. This number corresponds to uncompressed image bytes in Render
> requests that cannot be implemented with existing SPICE protocol
> commands.
>
> The "including nomask" number includes requests that could potentially
> be implemented with the existing AlphaBlend command.
>
> The conclusion is that adding Render acceleration will save around 88%
> bandwidth, but that around 17% of those could *possibly* be saved
> without changing the protocol.
>
> Some caveats:
>
> - With Render acceleration, some bandwidth will still be used for the
>    commands themselves. I don't know how much this will be precisely.
>
> - The numbers are before compression. It's conceivably that the types of
>    images generated by Render requests are more or less compressable than
>    those of other types of requests
>
>
> Soren
>
>
>
>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel



More information about the Spice-devel mailing list