5.84 KB, text/html
15.78 KB, application/xhtml+xml
5.65 KB, patch
|Details | Diff | Splinter Review|
Created attachment 483231 [details] Unpacked & unthrottled version of CPCBox JS JS CPCBox emulator engine. It is unpacked to stress that this bug report is in no way related to bug 599009. And speed is unthrottled in this version, I limit it at 50fps otherwise as per the real Amstrad CPC computer.
> Config A: Core2Duo@3GHz, 4GB RAM, Windows7 64-bit > Config B: Core2Duo@2.26GHz, 4GB RAM, Windows Vista 32-bit > Config C: Core2Duo@1.2GHz, 2GB RAM, Windows7 32-bit How big are the L2 (or L3, if present) caches on those machines? Since this is an emulator, does it have an array or something representing its memory? If so, how big is this array?
Did you disable hardware acceleration on all of them? A good graphics card on Config A could be inflating its performance.
(In reply to comment #4) > Did you disable hardware acceleration on all of them? A good graphics card on > Config A could be inflating its performance. After setting gfx.direct2d.disabled to true and relaunching the browser I get the same performance on Config A.
Sorry guys. I forgot to add the base href in the html file I sent as an attachment. And I don't know how to fix it in Bugzilla.
> The array size is 64K. As in 64,000 (or rather 2^16) entries? So 256KB for Chrome, 512KB for us. Shouldn't obviously be blowing out those L2 caches. Then again, who knows. ;) > After setting gfx.direct2d.disabled to true and relaunching the browser I get > the same performance on Config A. I assume "same performance" means 81fps? You want to set layers disabled too, if you're testing this. But I sort of doubt that's really being the problem here... > And I don't know how to fix it in Bugzilla. You can't. You can attach a new file and mark the old attachment as obsolete. I took the liberty of marking comment 7 as hidden so it won't clutter up the bug, since it looked like a mistake to me. Let me know if you want me to unhide it.
Looked up the specs on those chips, btw... in addition to the different L2 caches, they have different FSB speeds too (1333, 1066, 800 respectively). Other than that, the relevant bits seem to be about the same. So my money is still on the L2 cache issue here.
Created attachment 483259 [details] HTML using the attached JS
One other thing worth checking.... you're running the normal (32-bit) windows nightly on that 64-bit system, right?
(In reply to comment #12) > One other thing worth checking.... you're running the normal (32-bit) windows > nightly on that 64-bit system, right? Yep. It's the exact same 32-bit build that is used on all the configs.
Oh, interesting. With accelerated layers we should be doing that scaling on the GPU... and it should still be bilinear, I'd think. Certainly not a JS issue, though. Bas, any idea why we're doing nearest-neighbor scaling with layers?
Looks like the filters default to nearest-neighbour in D3D9: http://msdn.microsoft.com/en-us/library/bb172602%28v=VS.85%29.aspx Should be trivial to fix. Actually this should be honouring the CanvasLayer's mFilter. So should ImageLayerD3D9. There are two other questions worth exploring: -- why aren't layers enabled on machines B and C? -- why are we so much slower than Chrome 6 when layers are disabled? I guess we'd want separate bugs for those.
D3D9 does indeed not respect the mFilter. It was added after D3D9 layers I believe, and I only found out about it when I wrote D3D10 layers. It works in D3D10 layers. I'll fix it for D3D9 layers.
I have to correct myself. I forgot that config A had Chrome 7 beta installed when I did the benchmarks. I reinstalled Chrome 6 on it. Real Chrome 6 results on config A are 44fps, not 49fps. Sorry about that.
We go from surprise to surprise there. I just have upgraded the graphics drivers of config C. Config C graphics are based on Intel GMA (Intel Mobile 4 Series Express). I went from fairly recent Intel drivers v22.214.171.1241 to the newest v126.96.36.1992. This had much effect on Minefield. It is now hardware accelerated on config C. Minefield on config C now performs at 35fps with CPCBox!!! (That's 3x speedup!). Also, canvas scaling is not filtered anymore on config C.
So I think I have to detail the graphics configuration of the benchmarking platforms. config A: GeForce 9600GT 1GB - drivers v258.96 64-bit (latest official non-beta drivers from nVidia) config B: Mobile Intel 4 Series Express - drivers v188.8.131.525 (old drivers but I don't have the rights to change them) config C: Mobile Intel 4 Series Express - drivers v184.108.40.2062 (latest official driver from Intel)
(In reply to comment #17) > D3D9 does indeed not respect the mFilter. It was added after D3D9 layers I > believe, and I only found out about it when I wrote D3D10 layers. It works in > D3D10 layers. I'll fix it for D3D9 layers. Config A uses a DirectX10.0 certified graphics card (nVidia GeForce 9600GT). So either Minefield does not follow the D3D10 path or there is something wrong in the D3D10 path I think. Also, Intel claims DirectX10 hardware support on Mobile Intel 4 Series Express, but I honestly don't know if there's any truth in it :D
D3D10 is not currently enabled by default. You'd have to force it on using a pref in about:config.
The preference "layers.use-d3d10" seems to not have any impact. After switching that setting to true and restarting the browser, canvas scaling is still not filtered at all. I tested it both on config A and config C.
Check about:support to see if you actually got D3D10 layers. You may have to turn on the direct2d.enable pref as well.
You're right. Switching the setting gfx.direct2d.disabled to true make Minefield accept to accelerate with D3D10 instead of accelerating with D3D9. The price to pay is that small fonts are quite fuzzy then :/ Anyway, I confirm that D3D10 path is OK now both on config A & config C. And canvas scaling is filtered.
(In reply to comment #25) > Switching the setting gfx.direct2d.disabled to true ... To -false- i meant.
So there is still the issue with Minefield on config B refusing any kind of hardware acceleration no matter what. Here is relevant snippets of about:support Modified Preferences gfx.direct2d.force-enabled: true layers.use-d3d10: true Graphics Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family Vendor ID: 8086 Device ID: 2a42 Adapter RAM: Unknown Adapter Drivers: igdumdx32 igd10umd32 igd10umd32 Driver Version: 220.127.116.115 Driver Date: 7-28-2009 Direct2D Enabled: false DirectWrite Enabled: false GPU Accelerated: Windows0/1
I understand that it's probably partly graphic driver's fault, as what has happened with config C graphics driver upgrade. But I must stress that config B runs great with Aero compositing of the Vista desktop. So I don't think it's a good idea if Minefield hardware compositing system impose stricter requirements on the graphics driver than what Windows has for Aero compositing.
All but the most recent Intel graphics drivers are blacklisted at least for GL because they are very buggy (in the "if we try to use these, we or the OS keep crashing" sense), last I checked. Benoit, are they blacklisted for d39d too, for the same reasons?
Yes, they are blacklisted for all graphics features. We did have at least lots of D2D crashes with them so we decided to be safe and just blacklist all features. See this in widget/src/windows/GfxInfo.cpp. For this graphics card, your version 18.104.22.1685 is too old, you need 22.214.171.1242. I'm surprised that about:support didn't give you this hint: it should have since a few days. Is your Minefield build several days old?
Nope. I use the latest Minefield build. And I haven't seen any warning on about:support about Intel drivers blacklisting.
> -- why aren't layers enabled on machines B and C? I think we got that sorted out. > -- why are we so much slower than Chrome 6 when layers are disabled? I filed bug 604689. Note that on Mac without GL we're the same speed as chrome 7 dev, so the slowdown there seems to be Windows-specific....
(In reply to comment #15) > Oh, interesting. With accelerated layers we should be doing that scaling on > the GPU... and it should still be bilinear, I'd think. > > Certainly not a JS issue, though. Bas, any idea why we're doing > nearest-neighbor scaling with layers? D3D9 layers has a bug here I believe, it's easy to fix. Do we want to use this bug for that though?
Yes; I think that's the only issue left here that doesn't have a separate bug filed on it.
Created attachment 500215 [details] [diff] [review] Default to linear resampling and respect mFilter
Comment on attachment 500215 [details] [diff] [review] Default to linear resampling and respect mFilter r+ assuming that the D3D API, which I don't know, is decent enough that this does what it seems to.