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.
