[haiku-development] Re : Virtual CompositeEngine
- From: DERICK Eddy <eddyderick@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 1 Mar 2013 10:39:55 +0000 (GMT)
320x240 -- avg 255.00 (--rate 255)640x480 -- avg 255.0 (--rate 255)800x600 --
avg 168.22 (--rate 255)1024x768 -- avg 105.23 (--rate 255)1280x1024 -- avg
62.921600x1200 -- avg 42.021920x1080 -- avg 39.761920x1200 -- avg
35.522048x1536 -- avg 26.64
1000x1000 -- avg 82.64 (--rate 255)2000x2000 -- avg 21.003000x3000 -- avg
9.754000x4000 -- avg 5.535000x5000 -- avg 3.57
Intel i7 2600k (quad core 3.4ghz, hyperthreaded)
--- En date de : Ven 1.3.13, looncraz <looncraz@xxxxxxxxxxx> a écrit :
De: looncraz <looncraz@xxxxxxxxxxx>
Objet: [haiku-development] Virtual CompositeEngine
À: haiku-development@xxxxxxxxxxxxx
Date: Vendredi 1 mars 2013, 3h10
As I have mentioned in other e-mails on other topics, I've been working on a
stand-alone implementation of a highly flexible CompositeEngine.
I am releasing a gcc2 binary here:
http://files.looncraz.net/VirtualCompositeEngine-228.zip
The default test is 1024x768 @ 60Hz, but you can run it from Terminal and
change the buffer resolution and the frame rate - as well as see a little more
detail as to what is going on behind the scenes.
The test is designed to mirror a demanding load. Every pixel in the buffer is
updated for every frame. And each update requires at least four multiplies,
two divides, numerous additions, subtractions, bit shifts, and three
hard-to-predict branches. The load is almost 100% integer - as will be the
load in app_server.
The calculations are akin to drawing the entire Desktop and rendering two
transparent windows over the entire screen without optimizing the current code
in the app_server's rendering code-path (i.e. Painter).
The most interesting thing, perhaps, about the work is that the only locking
that occurs is for frame control. Even though there is one thread per core (up
to 8) accessing the same buffer. If you are familiar with Cinebench R11, you
will understand what is happening and why you see a grid in the rendering (the
grid is an overlay, as is the FPS).
Test results at different resolutions and on different hardware would be
greatly appreciated. I have done my best to make the app flexible and stable.
Later versions of this test suite will allow multiple-virtual monitor testing
in various configurations. Some code is already in place to show real windows
within the virtual screen and to run real loads to see how things work during
normal use. There is some overhead as a result running as a client - this can
be mostly removed merely by minimizing the window and watching the frame rate
in the Terminal.
Have fun!
--The loon
Other related posts:
