james.graham at oracle.com
Thu Dec 1 20:36:29 UTC 2016
Before we come to any conclusions on performance, though, we might want to run this on something like a Microsoft
Surface that uses a mobile processor (m3 in the low end) that might not perform as well with doubles. Does anyone have
a low-end Surface they could try these patches on and see how they affect performance?
On 11/30/16 2:12 PM, Laurent Bourgès wrote:
> As announced yesterday night, I made a new 'Double' (alias D) pipeline for
> marlinFX with 2 webrevs:
> - cmp that compares the D pipeline vs the float pipeline:
> - raw that makes no comparison to be easily applicable as a patch:
> As explained, I duplicated the complete pipeline (including
> MarlinRasterizer) so both can be used for comparisons.
> To enable the D pipeline, just add -Dprism.marlin.double=true else the
> float pipeline will be used !
> I left the conv.sh script that makes the 90% of the class conversions.
> It is very preliminary as I doubt we will keep two pipelines (for
> maintenance reasons) and here my test results:
> - DemoFX (stars / sierpinski) / GuiMark performance are so close that I can
> not really see any real difference on my linux with intel 7-4800 ; maybe
> other cpu may have more impact with double vs float but the floating-point
> computations are representing a minor part of the shape rendering (dasher,
> stroker, curve interpolation in Renderer)
> - Dasher issue with large shapes: all issues are fixed with marlinFX-D
> (rect, circle)
> - TestNonAARasterization: the errors seem are more important (poly, quad,
> cubic) so there may be either a bug in the test (Path2D comparisons) or an
> important issue in the D pipeline as also polygons are affected
> I wanted to present you this work to get your early feedback and mention
> the issues with TestNonAARasterization that will require some work to
> understand clearly what's happening !
> As I wanted to use double precision for long, I ported main marlinFX
>> classes using a tricky sed scripts... fixed the 'D' pipeline and it seems
>> already working well.
>> The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark
>> (webview) seems the same as the hot spot is in scanline processing +
>> coverage / mask processing, not in the dasher or stroker parts.
>> This first prototype is promising and it only took me few hours...
>> However, subdiving large curves is still an interesting option to preserve
>> quality / accuracy even with double precision as mentioned in my previous
More information about the openjfx-dev