Created attachment 46513 [details] Xorg.0.log According to 'man intel': Option "Shadow" "boolean" - This option controls the use of GPU acceleration and placement of auxiliary buffers in memory. Enabling the Shadow will disable all use of the GPU for RENDER acceleration and force software-fallbacks for all but updating the scan-out buffer. However Xorg just fails to start.
Created attachment 46514 [details] gdb-backtrace.txt
Looks like I accidentally fixed this by eliminating that code... Can you please confirm with master? And really, really, do not enable shadow for PineView, it's only an order of magnitude slower for the common cases...
(On the other hand, if you have a case where shadow *is* faster or you have stability problems, let me know!)
(In reply to comment #2) > Looks like I accidentally fixed this by eliminating that code... > Can you please confirm with master? Thanks, it works with git master now. I really had to check this with git master once again just before reporting. > And really, really, do not enable shadow for PineView, it's > only an order of magnitude slower for the common cases... That's exactly what I wanted to verify. And the fact that enabling shadow was not even possible (with older versions of xf86-video-intel too) brings some doubts regarding whether the relative performance with/without shadow is really being monitored ;) > (On the other hand, if you have a case where shadow *is* > faster or you have stability problems, let me know!) Some benchmarks with http://ie.microsoft.com/testdrive/Performance/FishIETank/ page: Internet Explorer 9 in Windows 7 : ~50 FPS Firefox4 in Linux without shadow : ~2 FPS Firefox4 in Linux with shadow : ~7 FPS Here the linux driver works much slower than its windows counterpart (not very surprising, considering that this page is really supposed to showcase specifically IE9). Still I'm a bit curious about how far the performance can be pushed for this webpage both with and without hardware acceleration: http://lists.freedesktop.org/archives/pixman/2011-April/001222.html The current cairo traces are a bit outdated and do not cover modern html5 use cases well.
(In reply to comment #4) > Some benchmarks with http://ie.microsoft.com/testdrive/Performance/FishIETank/ > page: > > Internet Explorer 9 in Windows 7 : ~50 FPS > Firefox4 in Linux without shadow : ~2 FPS > Firefox4 in Linux with shadow : ~7 FPS > > Here the linux driver works much slower than its windows counterpart (not very > surprising, considering that this page is really supposed to showcase > specifically IE9). Still I'm a bit curious about how far the performance can be > pushed for this webpage both with and without hardware acceleration: > http://lists.freedesktop.org/archives/pixman/2011-April/001222.html > > The current cairo traces are a bit outdated and do not cover modern html5 use > cases well. Agreed, and since everyone is diverging from even considering to use Render for their html5 canvas and layout engine, I need a broader set of benchmarks. Thanks for the fish tank link, let me see what tricks I have up my sleeve.
Hmm, first glimpse of the problem shows that firefox for the fishtank is using a 5kx5k texture. Ouch, no wonder shadow wins.
Ok, I can think we can achieve around 30fps with 20 fish (1024x495 window size) using firefox-3.6 on this N450. I hesistate because I don't it is rendering correctly, but I don't know the source of that bug...
(In reply to comment #4) > Some benchmarks with http://ie.microsoft.com/testdrive/Performance/FishIETank/ > page: > > Internet Explorer 9 in Windows 7 : ~50 FPS > Firefox4 in Linux without shadow : ~2 FPS > Firefox4 in Linux with shadow : ~7 FPS You wouldn't happen to know firefox performance figures for windows as well?
I have a branch at git://anongit.freedesktop.org/~ickle/xf86-video-intel sna that contains the nearly ready code that fixes this particular slow path, and many, many others. I would be very grateful if you do have a chance to test it.
Seems to be no visible performance difference here between 2.15.0 and 0e562ac075acf845734a7283eff8d80c0abaea23 from git://anongit.freedesktop.org/~ickle/xf86-video-intel sna for the fishtank test on Atom N450.
I'll try to downgrade to firefox-3.6 and check again (maybe it does rendering in a bit different way). Also do you need any additional logs or extra information? Changing the kernel between 2.6.37, 2.6.38 and 2.6.39 does not change anything either.
Siarhei, you also need to ./configure --enable-sna (grep SNA /var/log/Xorg.0.log to confirm that it is enabled). It's still not rendering correctly on PNV, so it should be pretty obvious when the switch is made. As the failure only appears on PNV, that suggests that is the code path for handling sources larger than the maximum texture size that is failing...
Created attachment 46989 [details] desktop crash on opening fishtank page for the driver from sna branch OK, now I have enabled sna (with a newer commit 214e7d16dfe625738bf23eb75404d4bfc20bbffc from that branch).
I think I've fixed both the segfault you hit and the incorrect rendering within the fishtank and have pushed it again to annarchy. It's almost ready for pushing to xf86-video-intel, but for the incorrect rendering of the gtk resize corner. I've also traced the fishtank demo with a 1000 fish and uploaded it to cairo-traces. The trace seems to reproduce a similar profile as running the benchmark directly in firefox and so would seem to be a good starting point for performance analysis.
OK, tried that. Now it runs, however the performance seems to be erratic, jumping between ~10 and ~60 fps (for 20 fishes, 1024x517 resolution). Also all the fishes facing left side are apparently not rendered at all. What do you typically use for the correctness verification? Is it some automatic tool like rendercheck? And thanks for this new cairo trace, it should be quite useful for benchmarking.
It's pretty steady at 45fps for 20fish and 30fps for 50 fish here, with the occasional drop which looks like GC. But I completely missed that there were meant to be fishes swimming to the left. Oops. Rendercheck is the first step, but that only tests the basics. After that I use the cairo-test-suite, and I try to make sure that is quite a comprehensive validation of the driver. What I've been aiming for recently is to use xtrace to capture a stream and replay that through the DDX and compare against Xvfb.
Fixed the invisible fishes. Needed to be careful to track the origin of the extracted texture, rather than computing the transformed offset from the top-left of the roi.
I landed sna in master which should fix this, smoothly.
I'm not going to fix this for UXA. The solution exists in SNA and could be ported across to UXA, but you don't want that change in isolation...
Fixed in SNA.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.