[OpenJDK 2D-Dev]  request for review: 8087201: OGL: rendering of lcd text is slow
philip.race at oracle.com
Wed Jul 8 16:12:31 UTC 2015
I think that is a reasonable compromise. Miminis 8ux risk but let's get
some exposure in 9 ..
Still, very interesting what Andrew notes about D3D being so much faster ..
seems like a subject for further study at some point.
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:
>> 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.
>> * ATI(AMD)
>> The NV_texture_barrier is available here, and the fix makes the
>> rendering 2-3 times
>> * 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:
>> 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
>> 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
>> lines 1007 - 1029):
>> What do you think?
>> 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?
>>> 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
>>> 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 ...
More information about the 2d-dev