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

[Sergey Bylokhov]

HI, Andrew.
The fix looks fine, but in my opinion we can add this ifdef to jdk8 fix 
to skip possible regression, but in jdk9 it is better to avoid this 
ifdef for two reasons:
  - This will increase a coverage of a new code not only on osx but also 
on other platforms and drivers.
  - It should be safe because, OGL is used by default only on osx.

I am fine with any decision, it is up to you and Phil.

On 03.07.15 17:24, Andrew Brygin wrote:
> 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.
>


-- 
Best regards, Sergey.