[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: Re: [OpenJDK 2D-Dev] Resurrecting Lauren'ts work on speeding up Pisces
From: Laurent_Bourgès <bourges.laurent () gmail ! com>
Date: 2014-01-28 6:42:42
Message-ID: CAKjRUT69_kNADwucxWFLLwUCkecBj7MgjsxfAqbfsYOxUtTbqQ () mail ! gmail ! com
[Download RAW message or body]
Dear Jim & Clemens,
I have made recently improvements to my pisces patch:
- initial array tuning
- use one 1d array for the AA stride (aa tile lines) instead of int [32][]
- use binary search in crossing sort for newly added edges instead of heap
sort
- use few system properties for workload tuning
- improved stats / monitoring
- revert many syntax changes
Finally as I adopted Andrea's approach and released last week end two
projects on github (GPL v2 + CP LICENSE) :
- marlin-renderer (pisces fork)
https://github.com/bourgesl/marlin-renderer
- mapbench (andrea's map benchmark)
https://github.com/bourgesl/mapbench
Marlin is JDK7 compatible.
The aim consists in improving and testing intensively pisces / marlin on
github but ASAP promote it back to OpenJDK 9 !
You can use / test both marlin and mapbench to find bugs and compare its
performance with ductus / latest pisces.
Ready to use mapbench + marlin 0.3:
https://github.com/bourgesl/mapbench/releases
Look at my mapbench results on windows, linux & macOS:
https://github.com/bourgesl/mapbench/tree/master/results
Ductus is only 10% faster on single threaded benchmarks compared to marlin
which is a pure java renderer.
Marlin is the winner on all platforms in multithreaded tests (server jvm is
10-20% faster than client jvm on windows).
Looking forward your feedback.
Best regards,
Happy new year,
Laurent
Le 12 nov. 2013 22:09, "Jim Graham" <james.graham@oracle.com> a =E9crit :
>
> Hi Andrea,
>
> I think the problem is that there really aren't a lot of people working
directly on the JDK any more with direct experience with rasterizers. For
my day to day responsibilities, I have been officially working on JavaFX
for a couple of years, but I am also the engineer with the most knowledge
about the rasterizer in the JDK, either the Open version or the Oracle
version. As such, I don't always pay attention to discussions here which
only occasionally bring up areas that I am familiar with, but I've worked
with Laurent in the past to provide feedback on improving the rasterizer.
>
> I've also wanted to drop the proprietary rasterizer in the JDK for a long
time, if we can get the OpenJDK rasterizer up to the same speed in the same
situations. I think Laurent was pretty much there which means if we can
get that work in then we might be able to delete one last proprietary plug
/ difference between the two JDK versions.
>
> Now that I'm aware of your efforts to continue that work, I'll keep an
eye out for this discussion more, but please feel free to ping me directly
if your questions aren't getting answered (note that addressing me directly
on the forum doesn't necessarily catch my attention due to mail filtering
unfortunately).
>
> JDK 8 is currently only accepting work that solves critical blocking bugs
at this point, so any work submitted now would have to go into JDK 9.
Getting it in to 9 early means lots of time to find bugs and have more
developers testing it by using it...
>
> ...jim
>
>
> On 11/11/13 12:33 AM, Andrea Aime wrote:
>>
>> On Mon, Nov 11, 2013 at 9:21 AM, Clemens Eisserer <linuxhippy@gmail.com
>> <mailto:linuxhippy@gmail.com>> wrote:
>>
>> Hi,
>>
>> One wish regarding pisces came into my mind:
>>
>> Currently all AA tile generators feed 32x32 coverage tiles to the
>> pipelines.
>> While this might be a good idea for software-only pipelines due to
>> good cache locality, it is a huge issue for at least the xrender
>> pipeline.
>> Each tile has to be uploaded seperately, which causes context
switches
>> and GPU stalls - and I can't make use of the shared memory image
>> extension which should be quite benefitial for larger coverage
>> uploads,
>>
>> It would be great if this fixed size could be made more dynamically =
-
>> this is an area where I could contribute.
>>
>>
>> Hi Clemens,
>> personally I'm on board with this and other changes, yet, the complete
>> lack of any response from Oracle people is a cold shower.
>>
>> As far as I know it's impossible to get the code in without any support
>> from them, so it seems like even if we started the work again, it would
>> be destined to failure.
>>
>> I still haven't looked in detail, but another approach I was considering
>> is to develop a improved rasterizer completely outside OpenJDK,
>> and just add in OpenJDK the bits needed to allow it being plugged in
>> (e.g., for example, by dropping a JAR and leveraging the usual SPI
>> mechanism)
>>
>> This I hope would break the tension between our desire to improve things
>> in software rendering, and the need to get Oracle support at every step
>> of the way
[Attachment #3 (text/html)]
<p dir="ltr">Dear Jim & Clemens,</p>
<p dir="ltr">I have made recently improvements to my pisces patch:<br>
- initial array tuning<br>
- use one 1d array for the AA stride (aa tile lines) instead of int [32][]<br>
- use binary search in crossing sort for newly added edges instead of heap sort<br>
- use few system properties for workload tuning<br>
- improved stats / monitoring<br>
- revert many syntax changes</p>
<p dir="ltr">Finally as I adopted Andrea's approach and released last week end \
two projects on github (GPL v2 + CP LICENSE) :<br>
- marlin-renderer (pisces fork)<br>
<a href="https://github.com/bourgesl/marlin-renderer">https://github.com/bourgesl/marlin-renderer</a><br>
- mapbench (andrea's map benchmark)<br>
<a href="https://github.com/bourgesl/mapbench">https://github.com/bourgesl/mapbench</a></p>
<p dir="ltr">Marlin is JDK7 compatible.</p>
<p dir="ltr">The aim consists in improving and testing intensively pisces / marlin on \
github but ASAP promote it back to OpenJDK 9 !</p> <p dir="ltr">You can use / test \
both marlin and mapbench to find bugs and compare its performance with ductus / \
latest pisces.</p> <p dir="ltr">Ready to use mapbench + marlin 0.3:<br>
<a href="https://github.com/bourgesl/mapbench/releases">https://github.com/bourgesl/mapbench/releases</a></p>
<p dir="ltr">Look at my mapbench results on windows, linux & macOS:<br>
<a href="https://github.com/bourgesl/mapbench/tree/master/results">https://github.com/bourgesl/mapbench/tree/master/results</a></p>
<p dir="ltr">Ductus is only 10% faster on single threaded benchmarks compared to \
marlin which is a pure java renderer.</p> <p dir="ltr">Marlin is the winner on all \
platforms in multithreaded tests (server jvm is 10-20% faster than client jvm on \
windows).</p> <p dir="ltr">Looking forward your feedback.</p>
<p dir="ltr">Best regards,<br>
Happy new year,<br>
Laurent</p>
<p dir="ltr">Le 12 nov. 2013 22:09, "Jim Graham" <<a \
href="mailto:james.graham@oracle.com">james.graham@oracle.com</a>> a écrit :<br> \
><br> > Hi Andrea,<br>
><br>
> I think the problem is that there really aren't a lot of people working \
directly on the JDK any more with direct experience with rasterizers. For my day to \
day responsibilities, I have been officially working on JavaFX for a couple of years, \
but I am also the engineer with the most knowledge about the rasterizer in the JDK, \
either the Open version or the Oracle version. As such, I don't always pay \
attention to discussions here which only occasionally bring up areas that I am \
familiar with, but I've worked with Laurent in the past to provide feedback on \
improving the rasterizer.<br>
><br>
> I've also wanted to drop the proprietary rasterizer in the JDK for a long \
time, if we can get the OpenJDK rasterizer up to the same speed in the same \
situations. I think Laurent was pretty much there which means if we can get that \
work in then we might be able to delete one last proprietary plug / difference \
between the two JDK versions.<br>
><br>
> Now that I'm aware of your efforts to continue that work, I'll keep an \
eye out for this discussion more, but please feel free to ping me directly if your \
questions aren't getting answered (note that addressing me directly on the forum \
doesn't necessarily catch my attention due to mail filtering unfortunately).<br>
><br>
> JDK 8 is currently only accepting work that solves critical blocking bugs at \
this point, so any work submitted now would have to go into JDK 9. Getting it in to \
9 early means lots of time to find bugs and have more developers testing it by using \
it...<br>
><br>
> ...jim<br>
><br>
><br>
> On 11/11/13 12:33 AM, Andrea Aime wrote:<br>
>><br>
>> On Mon, Nov 11, 2013 at 9:21 AM, Clemens Eisserer <<a \
href="mailto:linuxhippy@gmail.com">linuxhippy@gmail.com</a><br> >> \
<mailto:<a href="mailto:linuxhippy@gmail.com">linuxhippy@gmail.com</a>>> \
wrote:<br> >><br>
>> Hi,<br>
>><br>
>> One wish regarding pisces came into my mind:<br>
>><br>
>> Currently all AA tile generators feed 32x32 coverage tiles to the<br>
>> pipelines.<br>
>> While this might be a good idea for software-only pipelines due to<br>
>> good cache locality, it is a huge issue for at least the xrender<br>
>> pipeline.<br>
>> Each tile has to be uploaded seperately, which causes context \
switches<br> >> and GPU stalls - and I can't make use of the shared \
memory image<br> >> extension which should be quite benefitial for larger \
coverage<br> >> uploads,<br>
>><br>
>> It would be great if this fixed size could be made more dynamically \
-<br> >> this is an area where I could contribute.<br>
>><br>
>><br>
>> Hi Clemens,<br>
>> personally I'm on board with this and other changes, yet, the \
complete<br> >> lack of any response from Oracle people is a cold shower.<br>
>><br>
>> As far as I know it's impossible to get the code in without any \
support<br> >> from them, so it seems like even if we started the work again, \
it would<br> >> be destined to failure.<br>
>><br>
>> I still haven't looked in detail, but another approach I was \
considering<br> >> is to develop a improved rasterizer completely outside \
OpenJDK,<br> >> and just add in OpenJDK the bits needed to allow it being \
plugged in<br> >> (e.g., for example, by dropping a JAR and leveraging the \
usual SPI<br> >> mechanism)<br>
>><br>
>> This I hope would break the tension between our desire to improve things<br>
>> in software rendering, and the need to get Oracle support at every step<br>
>> of the way<br>
</p>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic