If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Layers-accelerated scaling is nearest-neighbor, not bilinear on at least some hardware configurations

RESOLVED FIXED

Status

()

Core
Graphics
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: phi2x, Assigned: bas)

Tracking

({regression})

unspecified
x86
Windows 7
regression
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [estimated-time: 1 day])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre
Build Identifier: 

I have tested my Javascript Amstrad CPC 8-bit emulator on 3 different hardware configurations.

So, here are the configuration details:
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

I have tested CPCBox with the latest Minefield release and with Chrome 6.
Here are the results:
Config A: Chrome: 49fps, Minefield: 81fps (+65% speed difference)
Config B: Chrome: 30fps, Minefield: 21fps (-30% speed difference)
Config C: Chrome: 18fps, Minefield: 13fps (-28% speed difference)

As you can see, on Config A, Minefield is just screamingly fast!
But while Minefield is much faster than Chrome on config A, it is much slower than Chrome on Config B and C :(
Given config A results, Minefield should perform at 49fps on config B and 29fps on config C. So, Minefield is more than 2 times slower than expected on those configurations :/

You can also note that Chrome performance difference between configs is coherent with what we can expect given the difference in hardware power. 
So the problem really lies in Minefield Javascript engine.

Reproducible: Always

Steps to Reproduce:
Quite tricky to reproduce I admit it :/

1. Launch the attached test-case on different hardware configurations, on Minefield and Chrome for each configuration.
2. To reproduce the problem, the tricky part is finding hardware configurations that exhibit that difference in Javascript performance I explained in this ticket.
Actual Results:  
Minefield Javascript performance is much slower than expected on some hardware configurations, having taken into account the actual hardware description and Chrome results on the same hardware.

Expected Results:  
I expect Javascript performance in Minefield to go accordingly to the performance of the hardware it runs on, like Chrome's Javascript engine.
A 2 times slower computer, giving 2 times slower Chrome speed, should also have 2 times slower Javascript performance in Minefield, not 4 times slower :/

The issue I described here is in no way related to the previous issue referenced as Bug 599009: https://bugzilla.mozilla.org/show_bug.cgi?id=599009
I confirm that Bug 599009 is 100% fixed in the latest release of Minefield on which I measured these benchmarks.
(Reporter)

Comment 1

7 years ago
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?
(Reporter)

Comment 3

7 years ago
Created attachment 483238 [details]
HTML using the attached JS

Comment 4

7 years ago
Did you disable hardware acceleration on all of them? A good graphics card on Config A could be inflating its performance.
(Reporter)

Comment 5

7 years ago
(In reply to comment #2)
> > 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?

Here are the details:
Config A: Core2Duo E8400. L2 cache: 6MB. No L3 cache.
Config B: Core2Duo Mobile P8400. L2 cache: 3MB. No L3 cache.
Config C: Core2Duo Mobile SU9300. L2 cache: 3MB. No L3 cache.

Yes, I simulate memory via a Javascript array. The array size is 64K.
(Reporter)

Comment 6

7 years ago
(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.
(Reporter)

Comment 8

7 years ago
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
Attachment #483238 - Attachment is obsolete: true
One other thing worth checking.... you're running the normal (32-bit) windows nightly on that 64-bit system, right?
(Reporter)

Comment 13

7 years ago
(In reply to comment #9)
> > 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.  ;)

Yep it's 2^16 entries (aka 65536 ;)

> > 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...
Yep that's what I meant. gfx.direct2d.disabled setting has no effect on performance on config A.

But it seems like you've nailed the problem somehow!
After modifying the setting layers.accelerate-all from true to false, Minefield speed went from 81fps to slow 28fps!!!
(The setting layers.accelerate-none hasn't been touched, it stayed to false all the time).
Reswitching the setting layers.accelerate-all to true makes Minefield goes again at 81fps. It is always reproducible.

There is also something I didn't mentioned because I didn't thought it was of importance, but this gives new light to it.
I render into a 768*264 Javascript canvas. I then double the lines displayed by doing some CSS canvas stretch to 768*528.
That stretch is bilinear filtered on Minefield with config B & config C, but on config A it is just plain line doubling, there is no filtering at all.
But when the setting layers.accelerate-all is set to false, and speed goes all the way down, the canvas is bilinear filtered on config A!
(Reporter)

Comment 14

7 years ago
(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?
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Graphics
Ever confirmed: true
QA Contact: general → thebes
Summary: JaegerMonkey is much slower than expected on some hardware configurations → Layers-accelerated scaling is nearest-neighbor, not bilinear on at least some hardware configurations
blocking2.0: --- → ?
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.
blocking2.0: ? → final+
(Assignee)

Comment 17

7 years ago
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.
Assignee: nobody → bas.schouten
Status: NEW → ASSIGNED
(Reporter)

Comment 18

7 years ago
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.
(Reporter)

Comment 19

7 years ago
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 v8.15.10.2141 to the newest v8.15.10.2202.
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.
(Reporter)

Comment 20

7 years ago
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 v8.15.10.1855 (old drivers but I don't have the rights to change them)
config C: Mobile Intel 4 Series Express - drivers v8.15.10.2202 (latest official driver from Intel)
(Reporter)

Comment 21

7 years ago
(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.
(Reporter)

Comment 23

7 years ago
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.
(Reporter)

Comment 25

7 years ago
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.
(Reporter)

Comment 26

7 years ago
(In reply to comment #25)
> Switching the setting gfx.direct2d.disabled to true ...
To -false- i meant.
(Reporter)

Comment 27

7 years ago
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: 8.15.10.1855
	Driver Date: 7-28-2009
	Direct2D Enabled: false
	DirectWrite Enabled: false
	GPU Accelerated: Windows0/1
(Reporter)

Comment 28

7 years ago
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 8.15.10.1855 is too old, you need 8.15.10.2202.

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?
(Reporter)

Comment 31

7 years ago
Nope. I use the latest Minefield build. And I haven't seen any warning on about:support about Intel drivers blacklisting.
(Reporter)

Comment 32

7 years ago
Created attachment 483451 [details]
Minefield output of about:support in config B
> -- 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....
(Assignee)

Comment 34

7 years ago
(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.
(Assignee)

Updated

7 years ago
Whiteboard: [estimated-time: 1 day]
Keywords: regression
(Assignee)

Comment 36

7 years ago
Created attachment 500215 [details] [diff] [review]
Default to linear resampling and respect mFilter
Attachment #500215 - Flags: review?(bjacob)
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.
Attachment #500215 - Flags: review?(bjacob) → review+
(Assignee)

Comment 38

7 years ago
http://hg.mozilla.org/mozilla-central/rev/c59ea33927d7
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.