[OpenJDK 2D-Dev] [9] request for review: 8087201: OGL: rendering of lcd text is slow

[Andrew Brygin]

Roughly speaking, the rendering of lcd text with d3d pipeline is 10-20 times
faster that with ogl:
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/ogl-d3d-hg5700.txt
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/ogl-d3d-nvs5400.txt

On windows, the suggested fix gives mixed results. It does not affect 
the case of
rendering to the screen, because in this case destination SD does not 
have a texture.
The effect on rendering to a volatile image depends on hardware/drivers 
config.

* Intel HD graphics
    There is no NV_texture_barrier extension, so effective parts of the 
change here is
     cache separation and the increase of cache celll size. It gives 
about x4 speedup
    for big glyphs. All other cases are not affected.
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/intel/hd4000.txt

* ATI(AMD)
    The NV_texture_barrier is available here, and the fix makes the 
rendering 2-3 times
    faster:
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/ati/hd5700.txt
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/ati/hd5770.txt

* NV
    here the fix causes significant performance degradation. A reason of 
this is
    is not clear to me yet. Probably it is due to significant overhead 
on synchronization:
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/nv/nvs5400m.txt
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/nv/quadro410.txt

So, the fix does not give significant advantage on windows (ogl is still far
slower than d3d in lcd text rendering), and even makes thing worse in some
cases. On osx (at least on 10.9 - 10.10) the fix helps to increase the 
rendering
speed up to 10 times.

Probably we can consider to use this approach for osx only (see 
OGLTextRenderer.c,
lines 1007 - 1029):
http://cr.openjdk.java.net/~bae/8087201/9/webrev.01/

What do you think?

Thanks,
Andrew





On 6/25/2015 8:08 PM, Phil Race wrote:
> On 06/25/2015 03:33 AM, Andrew Brygin wrote:
>>
>>> Given that it is a unified driver it sounds like we may be want
>>> to disable this code path when on windows at least for NV but I 
>>> guess we
>>> may also want to validate that on some other cards - from Nvidia - to
>>> see if it is a driver or h/w limitation.
>> Probably, we should to run the text benchmarks on relatively big set 
>> of windows
>> machines, and if we see that good performance of glCopyTexSubImage() 
>> is sooner
>> a rule than an exception, then we can just disable the new code path 
>> on windows.
>>
>> Wat do you think? 
>
> Yes.
>
> Also it occurs to me to wonder why we have not had the same 
> performance complaints
> when using D3D on Windows .. different APIs but they have the same 
> limitation.
> It would be interesting to know if objective performance tests on the 
> same hardware
> show that Windows users are more forgiving or it really is not a 
> problem there ...
>
> -phil.