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

[Phil Race]

I think that is a reasonable compromise. Miminis 8ux risk but let's get 
some exposure in 9 ..

So approved.

Still, very interesting what Andrew notes about D3D being so much faster ..
seems like a subject for further study at some point.

-phil.

On 7/8/15 9:02 AM, Sergey Bylokhov wrote:
> 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.
>>
>
>