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.
