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.gra...@oracle.com> a écrit : > > 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 <linuxhi...@gmail.com >> <mailto:linuxhi...@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
