XRender Java2D Backend stuff...

Nokia N9 .... and no glory at all :(

2011-09-27T11:50:00.000-07:00

So finally Nokia made sure the N9 wont succeed by setting an unrealistic high price point.
The first Nokia mobile with very positive reviews in a very long time and Nokia desperatly tries to make it loose - just to legitimate the switch to Windows Phone.

I wonder what had to go wrong, to make a company like Nokia decide to make itself completly dependent on a single software company and let in-house know-how and potential accumulated over the past 10 years just go away. Take Samsung for comparison - their Android smartphonse do really well - but just in case something unfourtunate would happen - they still have plenty of other options like Bada.

I can't help but to feel a bit sad, the 770 and N800 were great development platforms. Instead of just using the linux kernel and some non-unix userland (owned and controlled by a single company), that platform really was linux on a phone. My 770 is still used as internet gateway, firewall and postgresql server.

WebSockets for rescue

2011-09-01T11:46:00.000-07:00

Today I hacked together a prototype using WebSockets for data transfer, just to see how much it would gain - and the results are impressive! Over my high-latency line (~120ms ping) using http caciocavallo-web was barely useable, using websockets there was only a slight delay. Even moving internal frames arround felt almost smooth.

So it seems after all the work there is a chance for it to be more than a nice demo =)
Unfourtunatly by hacking the prototype together, almost all of the existing stuff has been broken - and it will require some serious refactoring to integrate it smoothly. But for sure it would be worth the effort :)

Now it's up to the html5/browser guys/girls, to finally spec WebSockets and implement the missing features like binary data transfer.

Load testers wanted ;)

2011-08-23T05:53:00.000-07:00

After fighting with memory-leaks in the demo-applications, as well as a concurrency bug in java.awt.EventQueue, cacio-web should be ... almost ... rock solid finally.
Guess AWT simply was never tested with 20+ concurrent sessions ;)

Even if tried already, in case you have some time left, please play arround a bit:
http://icedrobot.de:9091/SessionInitializer?cls=SwingSet2

Would be great to see it behaves also well under real-world load :)

SwingSet2 demo online - and focus issues resolved :)

2011-08-17T11:28:00.000-07:00

After a coding session last evening with Roman and Mario, we were finally able to sort out the remaining focus issues. Together with some event-handling fixes (no swallowed events anymore) and memory-leaks-plugs (one caused by SwingSet2 itself) I implemented things are coming together quite nicely.

Roman was so kind to host SwingSet2 on his vServer: http://icedrobot.de:9091/SessionInitializer?cls=SwingSet2

Enjoy :)

PS1: No idea wether it can handle the load, at the first announcement it ran out of servlet threads almost immediatly. Update: Ok server overloaded again, please don't leave it open for ages to avoid lurking sessions.
PS2: Keep in mind this was designed for low-latency lines
PS3: It still only supports german keyboards :p

RLE - image encoding

2011-07-25T09:34:00.001-07:00

As PNG was rather expensive for real-time image encoding, I implemented server-side RLE encoding. Compression for "typical" UIs yields about 120-200% the size of the equivalent png, however at a speed of about 300-1000mb/s on my 4 year old Notebook.

The data is sent to the client in binary format, and is decoded using JavaScript.
XHR1 for binary data transfer is also supported, but since XHR1 was never intended for binary-data-transfer it causes a performance hit.

IE9 was running on Win7 in Virtualbox (as all XHR1-Win7), however even under the same conditions, Opera/FireFox/Chrome were twice as fast.

Browser Benchmarks

2011-07-18T10:32:00.000-07:00

Cacio-Web needs to send image-data as well as a command-stream to the browser which is quite tricky to do. It currently supports three different ways to transport data to the client/browser:

XHR, text transfer, image data encoded as Base64. (traffic+, server load+, client load-)
XHR2, binary transfer, encoded to Base64 on client-side. (traffic-, server load, client load+)
PngImage, command-stream encoded in image and extracted with getImageData. Should be fast, but causes browsers to crash and eat tons of memory - so not benchmarked for now. (traffic-, server load-, client load?)

Long talk, short story - here are the results for rendering a 33.6k png image over and over measuring browser-only performance. FireFox does quite well, when more time is spent executing javascript code (XHR2) Chrome catches up:

All in all, its amazing in how many ways things can be done - all of them beeing suboptimal. I have to render an image to a canvas (which can cause precission loss) to be able to access its pixel-values. Even if I have the binary data in a ArrayBuffer, I have to pass image-data using data-URIs - that sucks.

Prebuilt demo release available

2011-07-13T06:35:00.000-07:00

With GSoC2011 midterm evaluations approaching, I've created a runnable demo release, available at:
http://93.83.133.214/cacioweb/cacio-web-x86.tar.gz

To run your favourite app, (e.g. SwingSet2), simply:

Untar the archive
download recent jre/jdk7 bundle from jdk7.dev.java.net for 32-bit Linux
copy libcacio-web.so into jre/lib/i386/ (or add it to the JAVA_LIBRARY_PATH)
Start the server environment:
java -cp cacio-web-runtime.jar:SwingSet2.jar net.java.openjdk.cacio.server.CacioServer
Start the app in your browser: http://localhost:8080/AppStarter?cls=SwingSet2

Please keep in mind this is only a demo release, a lot of stuff hasn't been implemented or is disabled to avoid problems, For now only german keyboard layouts is (somewhat) properly supported, however for toying arround the input support for us keyboards should be sufficient.

Have Fun :)

Interesting & ugly stuff

2011-07-03T13:57:00.001-07:00

The last few days I've been working on implementing copyArea acceleration, which is really a useful feature for faster scrolling. Instead of re-painting the whole scrolled area, only a small image of the "uncovered" are is sent to the browser - while the content already on screen is simply moved.
Supporting accelerated operations like this required quite a bit of tinkering with the code-base - accalerated operations require invalidated regions to be preserved before (which is why it wouldn't be wise to accelerate other primitives like fillRect too).
Long talk ... it still needs more work, because there are still artifacts. Other than that I am pleased with the performance results.

Now the ugly - keyboard events for now only work for basic characters on german keyboards.
Browsers are really broken in this regard. Sometimes the same keyCode is generated for different keys, sometimes keys can only differentiate by the order the keyPressed/Typed/Released events are generated.
All this is of course highly browser specific and without having an idea what keyboard layout is used actually, there isn't really a cure for the mess. Not so great idea to make a scripted document viewer the dominant runtime for distributed applications :/
Thanks a lot to the Joel Martin (Author of noVNC) who allows me to base my code on top of noVNC's input handling.

AppContext for rescue

2011-06-29T03:23:00.000-07:00

Yesterday I had a talk with Roman and Mario about AppContexts, and it turns out to be really useful.
Basically AppContexts are used inside AWT to shield one application/applet from others, create seperate Event-Dispatch-Threads for each app and so on.

Originally introduced for Applets I guess, this is exactly what I was looking for. Furthermore it solves the problem of out-of-http-request access to the surface. During an http-access I of course now which session I am on - but what if an application starts its own threads? Well, now each app knows its Session, as its stored in its AppContext.

It also allows for multiple LnFs set in the same server:

OpenGL pipeline works with the i915 open-source drivers

2011-06-07T02:00:00.000-07:00

Recently I updated my i945GM based notebook to Fedora-15 (mesa 7.11 pre-release) and gave the java2d-OpenGL pipeline a try again.

To my surprise, it worked:
jconsole -J-Dsun.java2d.opengl=True
OpenGL pipeline enabled for default config on screen 0
i915_program_error: Exceeded max nr indirect texture lookups (6 out of 4)
i915_program_error: Unsupported opcode: DDX

Its still dog-slow and crashes every now and then - but it clearly shows things are improving in the open-source opengl driver world. The OpenGL pipeline seems to be a rather tough beast, as it requires lots of extension/feature and even the proprietary nvidia driver break it from time to time.

Caciocavallo-Web at GSoC2011

2011-05-12T07:50:00.000-07:00

The Caciocavallo-Web proposal made it - during Summer I'll work on Caciocavallo-Web as part of GSoC2011.
Lets bring Swing to Web :)

Caciocavallo-Web proposed at GSoC 2011

2011-04-07T06:49:00.000-07:00

I proposed Caciocavallo-Web for Google Summer of Code 2011, the proposal is located at: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/linuxhippy/1

Would be great to work on a fun project and getting paid for, however competition will be tough, many really cool ideas have been proposed under the GNU umbrella.

If you like the idea ... I am thankful for all support I can get ;)

Now even with amd64 support ;)

2011-03-29T06:26:00.000-07:00

Over the last few weeks I fixed a few bugs oracle's QA Team found, ranging from XErrors caused by Xorg's weird way of freeing pictures asscociated with a Drawable, fixes to the SHM fallback path (this also affects the traditional X11 backend) and some bugs in the XRender glyph cache causing a Java2Demo running all night eating all your resources and causing your machine to crash ;)
What I never noticed however was, that the pipeline didn't work on AMD64. It seems nobody gave it a try on 64-bit machines. When text was rendered - only the first half was displayed.
The reason was that XIDs are defined as "unsigned long", even if they only contain 4-byte values as which the pipeline treated them.

Things look quite good so far for JDK7, except for one bug which causes IntelliJ's editor to be completly unuseable, caused by a different definition of the SRC operator with antialising enabled. Java2D still blends with the background, whereas XRender doesn't blend at all.
A simple solution would be to fall-back to software for SRC, better would be to switch to SRC_OVER when possible (src doesn't contain alpha), hope I'll find some time for that soon...

Caciocavallo goes Web

2011-03-04T16:11:00.000-08:00

Currently I am working on a small university project to "port" AWT/Swing to html5/canvas ... basically its more or less like VNC, except that browsers are far more clumsy to work with. (its only a scriptable document viewer after all).
The project is based on Caciocavallo, which already saved me a lot of work - all you need to provide is more or less a framebuffer and Caciocavallo takes care of the rest.

Although for now only rendering works (only for a single app) and input-event support is non-existent, the screenshot already looks quite nice :

Chaos 2011

2011-02-09T11:04:00.000-08:00

This year my trip to Fosdem was surrounded by chaos....

On Friday my Flight to brussels was delayed because of fog (in fact, we had to take a 2h bus trip to another airport), after ~14h of traveling I was just too tired to join you guys drinking ;)

The sightseeing planned on Friday now had to be done on Saturday/Sunday morning. When I arrived at Fosdem many talks I was interested in were full. Unfourtunatly no evening-event on Saturday.

On Sunday my backpack was stolen, including my passport. Missed the Gervill presentation, not in mood for evening-event...
Even with a notice of loss issued by the police and a copy of my passport I was not allowed to leave. Went by train, without a passport.
Had luck however, met David in the train who also attends the technical university vienna =)

So even if Fosdem-2011 was great again this year, I am a bit disappointed - didn't even find the time to talk to other attendees, which was what I was looking foreward to most.

After all, the talks as well as the exhibiting projects (really should give Haiku-OS a try soon) were awesome! Thanks everybody!

Fosdem

2010-12-07T02:01:00.001-08:00

Flights and Hotels are booked (thanks Lisi!), see you at Fosdem 2011 :)

XShmGetImage

2010-11-13T10:13:00.000-08:00

I really wonder what was the idea (or who had it) behind ommiting the width/height parameters from XShmGetImage:

Status XShmGetImage(Display* dpy ,Drawable d, XImage* image, int x, int y, unsigned long plane_mask)

Those two parameters where in XGetImage, even although an XImage is really cheap to construct client-side.
If you have to read back a certain area using XShmGetImage, either you create a fresh ShmImage (quite expensive) or you read back a too large area (also expensive, and sometimes not even possible).

I've been revently working a bit in OpenJDK's surface readback mechanism and this descision causes great pain there. Omiting those two parameters makes ShmGetImage only half as useful and efficient as it could be.

IE9 to be GPU accalerated - Firefox-2.0+ too ;)

2010-06-26T11:06:00.000-07:00

There seems to be quite a hype caused by the fact that the IE9 preview builds use Direct2D to accelerated HTML/SVG/Canvas rendering.
I always wonder why people didn't hype Firefox the same way, when FireFox-2.0 was released in Oct. 2006 it did exactly the same thing - using Cairo on top of XRender.
That was 4 years before Microsoft will release IE9 :P

FireFox-3.6 does even well on the IE9 canvas/svg demos:

(Granted, I had to scale down the background image, my weak intel-IGP has limited texture size of 2048x2048px)

Its also a good demonstration why the usual QT/KDE-Statement "we won't work on our XRender backend, the raster engine is faster anyway" isn't that clever.

Xrender pipeline now in JDK7 master :)

2010-06-12T11:58:00.000-07:00

The XRender pipeline has been integrated into the jdk7 workspace:

http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/5294c7067018

Thanks a lot to Phil Race who led the review-process and did many corrections and enhancements himself as I was/am rather busy right now.

This means from now on OpenJDK7/JDK7 will be shipped with the xrender pipeline included, but disabled by default for now.

The code integrated is the rewritten/new version, including the java-part of the "Jules" rasterizer-plugin which uses cairo for antialised rendering. I'll soon provide pre-built binaries of Jules for x86/amd64 as well as up-to-date sources. Whats missing is the pure-java protocol generator, its not ready yet.

In order to use the xrender pipeline simply grab a recent enough OpenJDK-7 build, or Sun's closed source JDK7-b97+ and pass -Dsun.java2d.xrender=True to the runtime.
Should work on recent Linux and Solaris distributions.

So whats next:
- Bug fixing, so grab a build and cu on OpenJDK's Bugzilla ;)
- Porting Jules to Cairo-1.10 (should improve performance when used as AATileGenerator for BufferedImage targets)
- JDK7u10 enables the pipeline by default ;)

Linux Desktop Experience

2010-05-14T10:37:00.000-07:00

Today I decided to update the Fedora-10 installation on my father's PC.
Its an old Athlon-600 with 384mb ram, KDE4.2 was way too heavy and the proprietary nvidia driver didn't accelerate 2D stuff well - the overall desktop experience wasn't so pretty.
I thought installing a modern distribution using the lxde desktop would help here, and nouveau would provide descent EXA/2D support.

1. Installation of Fedora-13-Rc3 LXDE spin live cd failed, "Install to Disk" simply aborted.
2. Downloaded Fedora-12 LXDE spin live cd, didn't boot at all.
3. Downloaded Ubuntu-10.04. Azureus crashed on my Laptop in Hotspot's server JIT.
Installation worked well, however only used fbdev - nouveau backtraces in dmesg.
4. Went to Ubuntu Launchpad, registered for an account, filed a bug and .... launchpad reported timeouts.

So of course, I can make Linux work on Desktop, however to be honest ... I doubt an average PC user would be able to solve the problems mentioned above. This is a boring, old computer without any fancy hardware.

OK here's another one:
5. Tried Fedora-13 Netinstall, refuses to start graphical mode because too little ram (384mb + 1gb swap)
6. Anaconda in text mode is *crap*. Partition manager non existent (and buggy!), ugly LVM based default partitioning, no package selection.
7. Install Lubuntu 10.4 + proprietary nvidia driver. Works well (horray!)

Prebuilt jre-image available

2010-04-22T10:21:00.000-07:00

For testing-purposes I've created pre-built jre packages for x86 available at:
http://93.83.133.214/jre-builds/

To try it, simply pass -Dsun.java2d.xrender=True to java, e.g.
> bin/java -Dsun.java2d.xrender=True -jar demo/jfc/Java2D/Java2Demo.jar

Those OpenJDK based builds contain the latest xrender sources, as well as the Jules rasterizer.
I'll try to keep those builds in sync with jdk7 master as far as possible.

Have a lot of fun :)

Fglrx to get XRender hw acceleration

2010-02-20T12:41:00.000-08:00

According to Phoronix fglrx (AMD's closed-source graphic driver) has experimental support for accelerating 2D, I guess that means XRender (too?). I've been told for a long time by an AMD guy they are working on this, however after waiting for over a year I already gave up hoping for improvements.

Basically this is really great (if they produce something useable), because now *all* drivers have solid XRender support:

NVidia's proprietary drivers are best in class, doing even Trapezoids on the GPU (for GTX260++)
All major open-source drivers (intel, radeon, nouveau) support XRender quite well
Hopefully soon fglrx will accelerate it soon too.

So basically 95% of hw in use has drivers with quite good XRender support :)
And even on hardware/driver combos that don't accelerate it well, pixman fallbacks shouldn't be much slower than what java does with its X11 pipeline.

I would love to see it enabled in JDK7 by default, even it that would mean a lot of work + compatibility testing. JDK7 is still early enough to get serious testing. As optional pipeline, it seems notbody uses it (or it just works) ;)

vServer troubles

2010-02-03T13:18:00.000-08:00

me: Hi, my vServer has been shut down. Could please start it again?
Support: You were running tor. This is not permitted.
me: I only found paragraphs about IRC. Where is tor mentioned?
Support: In the AGB.
me: I made a copy of the contract and it only says IRC servers are forbidden.
Support: Another machine has been hacked from your tor server.
That was the reason we took you offline. We will sue you.
me: My tor is configured as relay only, its not an exit node. Therefor no hacks are possible.
Support: I won't discuss that any further. Please send an email to support@ ......

Bottom line is my vServer is up again, nobody has been hacked, and nobody will sue me ;)

Large fill optimizations

2009-12-08T13:32:00.000-08:00

Frustrated of learning for exams I fixed/enabled an optimization for large fills, which I had implemented some time ago, but which wasn't working properly.

The results are quite pleasing:

At least for large operations Jules is now really close to ductus, although its burning significantly more cpu cycles using two threads.
I am still not sure the whole multi-threading is really a good idea, however the fill optimization mentioned applies to the single-threaded version alteady released as well :)

Multi-Threading Jules

2009-11-10T11:27:00.000-08:00

I played with the idea of making Jules multi-threaded, by rasterizing the trapezoids using multiple threads.
For large shapes it does improve things quite a bit (on my Core2Duo notebook):

Hey, in one case jules now even beats ductus :)

However it reminded me again how hard it is to write well performing multi-threaded code in real-world.
The outcome is a 2-thread producer/consumer implementation, where the consumer can produce for itself if it has catched up with the producer.
The first implementation (multi-unopt) simply fetched idle tiles from a pool, and added rasterized tiles to another one. And there was a volatile variable for communication. That makes 4 uncontended monitorenter/exit + volatile read/write.
With that approach the synchronization overhead eat up almost any speedup, in some cases I even saw ugly regressions.

I now batch fetch/store from the idle/completed tile lists in order to minimize synchronization costs, as well as let the worker start a bit ahead of the consumer.

I am still not sure wether the whole effort makes much sence, it makes the whole thing quite complex.
After all, it was fun ;)

I wonder how much speedup can be archived by using profile-driven optimizations and -O3 when compiling pixman and jules. I guess arround 10-20%, which could be enough to push threaded Jules in front of ductus.

"Jules" cairo binding 0.0.1 release

2009-11-05T12:04:00.000-08:00

I've prepared a webrev/patch of the XRender Java2D backend based on jdk7-master. It also includes a preview of "Jules", a cairo based RenderingEngine implementation, for faster antialiased rendering.

Please note Jules is more or less proof-of-concept, especially the native code is ugly, full of dirty assumptions and its probably not 64-bit clean.
However it runs Java2Demo quite well, and usually is a good deal faster than pisces even when rendering to software-surfaces. (and a *lot* faster when rendering to XRender surfaces), especially with the client-jvm.

Because of the need for a modified version of cairo and its complex build-system, I've seperated the native components and build them indepent from OpenJDK - falling back to pisces when loading fails.

Howto:

1.) Download
The webrev can be downloaded from:
http://93.83.133.214/webrev-xrender-jules-0.0.1.zip

The native jules/cairo code is located at:
http://93.83.133.214/jules-0.0.1.tar.gz

2.) Patch
To patch your local jdk7 repository, just do
> hg import ~/webrev/jdk.patch
or if your hg has that option:
> hg import --no-commit ~/webrev/*.patch

3.) Build
- Build your JDK as usual
- Compile Jules by running build_jules.sh (some makefile guru here?) ;)
- Copy libjules.so into build/linux-i586/lib/i386 or elsewhere, where it can be found by the JVM

4. Use it
Simply adding "-Dsun.java2d.renderer=sun.java2d.jules.JulesRenderingEngine" should do the trick :)
In addition you can enable the xrender-backend too, "-Dsun.java2d.xrender=True".
If everything works you should see:

XRender pipeline enabled
Jules library successfully loaded

Known problems:
- Some clipping problems when rendering to software surfaces
- Paints get wrong transformation when rendering to XRender surfaces

Last but not least the usual screenshot:

Update: Unfourtunatly my Nokia-770 where the stuff is hosted went down. Its up&running again.

cairo integration continued...

2009-11-01T10:54:00.000-08:00

The cairo guys made clear the functions in use are subject to change anytime, and won't be exported.
I'll create a custom cairo-version as shared library, which will include the JNI-binding code, with a different name.

That will:
- Not change the OpenJDK build process (just add a few pure-java files to it)
- Provide native code that fullfills all the assumptions I need.
- Allow distributors to package it as an extension library, if they wish to enhance performance of OpenJDK.
- Allow us to detect at runtime, wether the native rasterizer is available and fall back to pisces if not.

Unfourtunatly it will also waste a few KB of your disk ;)

What to do with the Cairo rasterizer?

2009-10-29T13:44:00.000-07:00

I've the cairo based rasterizer on my disk, and to be honest I don't really know what to do with it.
I'll release it hopefully soon ;)

Pros:
- A lot faster than pisces, could be speeded up further by some optimizations as well as multithreading.
- Runs Java2Demo perfectly, even gets some things right pisces fails at.
- Better image quality than pisces

Cons:
- Uses private cairo symbols
- Uses a modified version of cairo (one line commented out).
- Writes into C structures from Java-code
- Currently depends on the XRender pipeline code a bit.

There are some really dirty assumptions in that code that could break from one cairo version to another, but they are there for performance reasons. The more clean you make it, the more performance you loose.

Actually I don't see the modified cairo version as a bit problem itself, because if I wouldn't have used cairo and written a rasterizer from scratch in native code, the code would be there too - and nobody would care about it. The problem however is, cairo's codebase is huge, and nobody wants to integrate a private version of it of course.

Any ideas howto "solve" that dilemma? I doubt the cairo guys would open up their interface, not to the level I am using it.

Mercurial struggles

2009-10-20T09:22:00.000-07:00

I've today fixed the cairo bindings, to correctly generate cubic bezier curves out of quadratic ones.

I don't see any correctness bugs running Java2Demo anymore, at least when rendering to BufferedImages - rendering to VolatileImages triggers some problems in an optimized path when using Texture/Gradient paints.

However I've real troubles publishing the code. I am working on OpenJDK revision 1421, but how do I get the latest JDK without destroying my work. I executed "hg update -C" some time ago, and all files I altered were overwritten by the files in the repo.
I've already given up maintinaing my personal xrender repo, because it caused me even more struggles.
Would be glad if some mercurial gurus could assist me.

Ductus vs Cairo vs Pisces

2009-09-12T08:57:00.000-07:00

Today I got the AATileGenerator based on cairo into a useable state. This way software-rendering is done by cairo instead of the pisces rasterizer.

The relative results are quite pleasing:

On the positive side, most benchmarks improved by a factor of 2-3x :).
However cairo is no cure-all. The ductus rasterizer used in Sun's proprietary builds is still the winner in all tests.

Most likely this is the result of cairo beeing a two-step design:
First a path is tesselated into trapezoids, and later those trapezoids are rasterized, whereas ductus rasterizes directly.
However a positive side-effect of this design is trapezoid rasterization can be parallelized, so on dual-core systems it should be possible to get close to ductus.

Running Java2Demo on cairo's tesselator

2009-09-08T16:34:00.000-07:00

I've just sorted out the worst problems, and its possible to run Java2Demo using the Cairo based rasterizer now. The hardest part was a small bug in cairo, which was caused by the uncommon situation how cairo is used.

Performance is excellent compared to pisces, and quite good compared to ductus.
By implementing more specific functionality (not only draw/fill) it should be possible to get even better performance for common cases like arcs or ovals.

A drawback is that this rasterizer backend needs a private version of cairo, because its tapping a lot into cairo internals. Hopefully this will find its way into IcedTea some day...

Using cairo for antialiasing

2009-09-04T11:56:00.001-07:00

I've written some glue code to use Cairo's tesselator to generate trapezoids for antialiased rendering, which can be directly fed to the X-Server. With a little more work, pixman could be used to generate AA tiles which could also be fed to the software loops (e.g. BufferedImage rendering) - replacing the slow pisces rasterizer currently used by OpenJDK.

For now I've only implemented the (simple) fill operation, stroking/drawing is still missing - however the results look already quite fine:

Boring background:
Currently both OpenJDK as well as Sun's proprietary JDK builds implement antialiased rendering by computing coverage values using C/Java code on the CPU, uploading those coverage values to the GPU and finally do blending on the GPU.

D3D/OpenGL drivers are usually highly optimized, so this works quite well there. For XRender however, especially with the Intel drivers (*cought*), this results in quite low performance, because every operation involves a syscall + a full GPU flush.
Furthermore when using OpenJDK, the rasterizer generating those coverage values is horribly slow, so AA rendering to any surface suffers.

Traffic shaping on the Nokia 770

2009-08-01T09:27:00.000-07:00

Thanks to the Mer project (Ubuntu-9.04 for ARM5TEJ + some tablet specific optimizations) I now can revive my Nokia 770 to replace the old P90 server. Because of its low power consumption I can keep it running 24/7, hosting a tor-relay to make use of otherwise unused traffic, and using traffic shaping to not let tor interfer with "real" workload.

However the 770's wlan driver is a binary blob (umac.ko), and enabling certain networking features (like QoS needed for trafic shaping) change the size of the sk_buff structure, which breaks it.

To be able to enable traffic shaping (and other features), you can steal some memory from the command buffer:
/include/linux/skbuff.h / line 254::
char cb[46]; //-2
__u16 tc_index;

This is really ugly and unsafe, may lead to real troubles and could cause whatever disease you can think of.
However it seems both, wlan-networking as well as traffic shaping work perfectly fine now :)

Shame on HP

2009-07-29T13:42:00.000-07:00

Shame on HP for not phasing out PVC and BFR, althout other manufacturer clearly demonstrate it can be done!
In 5 years all those computers built today will rot in China&Africa, polluting our enviroment.

Kudos to Captain Kirk ;)

Driver bugs (and how quick they _can_ fixed)

2009-07-06T15:51:00.000-07:00

Recently I found exactly the same driver bug in RadeonHD on my RadeinHD3850, I've reported for <= Intel-945 about almost a year ago. The bug probably would not be worth mentioning it, however Tungstengraphic's Roland Scheidegger fixed the bug 3 weeks after I've reported it.

The problem seems to be an off-by-one-half problem, causing images which are scaled on the x-axis to be also blurred on the y-axis. The first line is rendered with pixman (reference), the second with Intel-2.8.0pre on my i945GM:
No big deal, unfourtunatly it makes Nimbus look pretty ugly :-(

There is quite a long list of driver bugs and performance problems I reported against the Intel driver in the freedesktop bugzilla. So far a single pipeline related bug has been fixed (and only for i965 and up, not for the i945 I call my own). Even for bugs causing image rendering corruptions in firefox nothing happens.
Despite the fact that the last two stable releases (2.6 & 2.7) can hardly be called "stable" and are driving distributors crazy, there are major performance regressions.

Hopefully that problems will be resolved soon, however time told a different story in the past.

Only good news ;)

2009-06-25T08:12:00.000-07:00

Tomorrow my holidays begin, after my bachelor thesis presentation I will hold at the computer graphics institute at the Technical University of Vienna and an exam two hours later.
Its basically the same presentation I held at Fosdem09, spiced up a bit with the most boring parts removed. Needless to say I prefer a 15min talk a lot over a 30min talk ;)
A big thank you to Hans-Peter Bernhard, my previous informatics teacher, who made all this possible.

Furthermore the xcb guys seem to have found the reason why the pure-java backend blocked (thanks a lot to Jamey Sharp). I haven't had the time to try it out, hopefully it will solve the problems and make the pure java backend finally useable after all.
If somebody would tell me tiered compilation would be enabled in JDK7 for sure, along with saturated cast instrincts (6850613) my day would be perfect ;)

So far ... only good news :)

Rewrite ... finally

2009-06-06T00:44:00.000-07:00

Finally the rewrite version is available in the repo.
It is not production ready and still has a few known bugs.
At least it builds ;)

Took me ages to start fighting with mercurial, however turned out to be a lot less horrible than expected.

The rewrite version features two different backends, for now only the native backend is functional.
You can find more details here.

JXRenderMark 1.0 released

2009-05-20T21:17:00.000-07:00

JXRenderMark 1.0 has been released, you can download it here

Thanks to a contribution made by a major GPU vendor who uses JXRenderMark for nightly performance regression testing, the results are now more stable and the benchmark runs faster. Thanks again!
Furthermore the "Transformed Blit Billinear sharp edges" test has been corrected, as well as small adoptions to the blit tests have been made.

Please give it a try on your system, and submit the results along with a short description of your system.
I am especially interested in (with EXA enabled):

open-source radeon driver, R100-R500, R600/700 with DRM+EXA
Unichrome
Intel <= i865

Austria to quit CERN engagement

2009-05-18T05:12:00.001-07:00

Austria plans to stop its CERN engagement to save anual ~26M €, because we are so thight on budget.

- Currently you get 1.500€ for your old car if you buy a new one. No matter where it was produced.
- We spend ~40M € per year on Euratom, although we don't have a single nuclear plant and did decide to never build one. (well, thanks to ...., .... built us one in the 70' but we never switched it on)
- Austria just lost 1,5B €, because a bank went bankrupt we lend money to.

In 2009 and 2010 Austria will set a new all-time record for new national debts and all I saw this morning were government advertisments in the newspaper how well they work.
Its seems its all about choice, the questions is between what.

Sw->Surface Blits

2009-05-16T09:30:00.000-07:00

Recently I've implemented SW->Surface blits. Those code paths are used if an image is not cached (first use or not cacheable), e.g. when blitting a BufferedImage with stolen raster which some programs do quite frequently.
I avoided that stuff for a long time, because I didn't want to touch the whole well tuned image-upload code which is shared with the X11 pipeline.
For now a new VolatileImage is created every time the image is blited, using it later for composition - which is probably not an optimal path - but a lot less code ;)

> sun.java2d.xr.XrSwToPMTransformedBlit::TransformBlit(IntArgb, AnyAlpha, "Integer RGB Pixmap")
> sun.java2d.loops.Blit::Blit(IntArgb, SrcNoEa, IntRgb)

Update: Ok admited, it reuses the VI now for better performance ^^

XOR rendering

2009-05-03T07:45:00.000-07:00

The last few days I've been busy with cleanups and refactoring, today I implemented acceleration for the infamous XOR mode. Modern applications don't use it very often, but many older apps rely a lot on it, and especially for the remote case fallbacks would kill performance. (I'ts not very fast in the local case either).
XRender doesn't support bitwise-XOR, so the pipeline has to use the X11-GC which adds another few lines of code for state-tracking and another bit complexity:

Native Backend

2009-04-23T11:00:00.000-07:00

Because of the deadlock-problem when using xcb's socket handoff mechanism required for the "pure java" approach, I factored all stuff out into an interface and wrote a jni based backend. This will make the pipeline also work (when it works) on systems without recent xcb based xlib.

The plan is to have multiple backends:

Pure Java (self generated X protocol)
Native (using X11+libXrender through JNI)
Escher planned, for integration with Caciocavallo.

The whole rewrite-code is an ugly mess, hopefully I'll soon find some time to clean it up soon.

And of course ... Java2Demo on the native backend:

Cacao Jit Cache

2009-04-22T03:28:00.000-07:00

Congrats again to Robert Schuster who held his diploma thesis presentation about implementing a JIT cache in Cacao at the TU Vienna yesterday.
Really cool and interesting work and excellent presentation :)

Hmm, by the way ... thanks for offering me to sleep in your hotel room on the floor at Fosedem ;)

UXA ... unuseable slow

2009-03-18T01:58:00.000-07:00

I just recently filed a bug about horrible performance when runnig the existing X11 pipeline using intel's forked UXA accaleration architecture. AWT applications are extremly slow, hardly useable.

> We don't intend to fix this in UXA ourselves. If you're drawing unantialiased
> text in 2009, your software fails. If you're not using Xft or cairo for text
> drawing in 2009, your software fails even harder (it would perform fine if you
> were).

So, it seems intel doesn't care they broke your software :-/

Shader Trapezoids

2009-03-05T17:25:00.001-08:00

Lately I've been playing with shaders a bit, investigating the possibility of implementing XRender's more complex features (trapezoids and gradients) using shaders instead of falling back to software all the time.

I started with trapezoids because they're used a lot, and because pixman's strange implementation made me curious:

I used NVidia's Cg language because it can be compiled down to ARG_fragment_program, which is the best my i945GM can do. Performance could be better and I am limited to 0,25px subpixel precision because of the i915's 64 ALU instruction limit.
But at least from what I can tell the traps should conform to the spec for imprecise trapezoid mode (default), I'll try to feed some cairo output at it and see what will go wrong ;)

On my i945GM I get 25fps fullscreen, a RedeonHD3850 is able to do ~1000fps and is still not ALU limited :)

Hopefully some day that stuff will find its way into one of the opensource drivers, I guess on more powerful hardware like AMD's R600/700 GPU setup costs will dominate :)

Fosdem

2009-02-12T06:41:00.000-08:00

Fosdem was really cool and exciting.
Many interesting talks and a great way to meet all the people I've mailed or heard about ... and all those I haven't known before .... and drink some beer with them.
I am really looking foreward to next year's fosdem, thanks guys for the great time :)

The Caciocavallo talk was quite impressive (although I still have troubles with pronouncation), I guess their work will boost Java's popularity for embedded systems. Unfourtunatly I missed the first part of Karl Helgason's talk about Gervill.
My talk went ~ok I guess, nobody fell asleep. I just talked a lot about not really related stuff like Java2D in general to get my 30min filled somehow. Thanks nobody recorded videos ;)

Unfourtunatly Java talks colided with some Xorg talks I planned to attend, however Michel Dänzer talked to me after my presentation about some problems I had with X :)
The open-source radeon/ati driver is in a pretty good shape, once intel is stable and fast again and radeonhd pushes the r600/700 branch to mainline, we have >80% of hardware with good drivers (Hopefully in Fedora11), with the only exception of AMD's Catalyst.

Michel had a great idea about how handling fallbacks better. Currently there are several different heuristics when to move a pixmat to video-memory and when it should stay in system-memory.
The problem is such heuristic descisions are based on what happend in the past, which often means its hard to get it right - better would be a prognosticator to get an idea what will happen in future ;)
A way this could be archived would be some kind of delayed rendering:
All rendering commands could be buffered in a queue of e.g. 50 entries, and the current operation could make migration descisions based on what it knows to come. If the current operation could be done on the GPU, the image contents are in RAM and in the queue are 5 operations triggering a fallback, it may be more efficient to not move the image to VRAM and do work by the CPU, avoiding the later readback to RAM altogether.
This would help drivers/GPUs which provide only basic RENDER accaleration, like Nouveau with <= GF5 or for frequently use of unaccalerated stuff (AddTraps, A1 masks, frequent XGetImage, ...). If the queue is not full, X processes painting commands faster than the client so less optimal descisions would not hurt (the smaller the queue, the more it behaves like default the "Always" heuristic). However would be a lot of work especially without deep knowledge of the code , I'll have a look in the Summer holidays :-/ Back to the pipeline ... I am still distracted by the problem with xcb's socket handoff mechanism, no idea whats going wrong. If somebody knows xcb (and unix sockets, ...) a bit, I would be really happy for any help.
Its not a lot of fun to work on a pipeline locking up after 5s, without knowing the cause :-/

QT rocks :)

2009-02-05T14:26:00.000-08:00

I investigated the poor performance QT4 showed at QGears2 in the aliased case. (20fps vs. 80fps antialiased)
QT was using XRender in a quite inefficient way for the aliased case, as well as Xorg falling back to software although it could clearly do better. I hope I can fix that, shouldn't be too hard.

I sent them a mail, and after a short discussion a patch was written by trolltech targeted for 4.5, improving the performance of aliased shapes by a factor 2. Once Xorg is fixed performance should double again.

Sometimes its really a big plus to have a company behind an open source project maintaining it, like its the case for OpenJDK or QT. Some other projects I tried to contribute are in a far worse state.

Fosdem, Mozilla, RadeonHD, Intel

2009-01-26T02:21:00.001-08:00

Fosem:
I'll talk a bit about the pipeline at Fosem 09.
I got a 30min slot assigned, no idea what I should talk about half an hour ;)

Mozilla / RepeatPad:
The XRender pipeline has to use RepeatPad for transformed and scaled images, however this is only accalerated by NVidia and Intel for now.
Mozilla now discusses the switch to RepeatPad (eliminates some artifacts and allows billinear scaling), which has already led to a series of bug-reports.
Update: the open-source radeon driver already has experimental RepeatPad accaleration for R100-R300 :)

RadeonHD:
AMD is currently working on XRender accaleration for their Radeon HD series in a seperate git tree.
Hopefully it will be merged into mainline soon, and in the long term I hope it will make its way into the proprietary Catalyst drivers.

Intel:
Intel has released 2.6.0 and soon after that 2.6.1. Hopefully their GEM refactoring is finished soon, the driver is now in a fairly bad shape.
Performance is bad and non-GEM related bug fixing seems quite halted.
There's still an off-one-half bug on i915/i865 which makes Nimbus look ugly on my 945GM as well as several performance regressions which affect antialiasing :-/

No Software Patents! (again!)

2009-01-22T15:16:00.000-08:00

Please subscribe to the Stop Software Patents Petitition: http://stopsoftwarepatents.eu/

Nobody needs software patents, except patent trolls.
Writing code should be no crime - but with those thousands of patents its almost impossible to not interfere.

Examples of what can be patented in the EU:
- Selling over a mobile phone network - EP1090494
- Video streaming (segmented video on-demand) - EP633694
- Electronic shopping cart - EP807891

fillRect overhead analysis

2009-01-08T07:11:00.000-08:00

Ever since working on the pipeline I've been interested where how many cycles are spent in which parts.
Today I profiled fillRect a bit:

Protocol generation: 120 cycles (40%)
Pipeline overhead : 90 cycles (30%)
Locking/synchronization: 90 cycles (30%)
Total: 300 cycles with server compiler (480 cycles with client compiler; ~20.000 cycles interpreter-only)

Protocol generation is writing the X11 protocol into a sun.misc.Unsafe.
Pipeline-Overhead is all the work done to validate pipeline/surface state and decide which code-path to use for the current operation, as well as all the abstraction from Graphics2D up to our XRender Surface.
Locking means aquiring/releasing a ReentrantLock, which guards AWT access.

Conclusions:
- 300 cycles is not that well, however we are generating rectangles probably faster the XServer can process it :). After specific optimizations as well as biased locking I guess 175 cycles is realistic, which is not that bad.
- The server-compiler does pretty well, hopefully tiered compilation will be implemented for JDK7. In this case the client-compiler produces 60% slower code :-/
- Locking is expensive, especially on older muti-core processors (like my Core2Duo). Biased locking could really help here, unfourtunatly it has a limitation which make it hard to use for the pipeline.
Furthermore it seems some optimizations don't have any effect when locking is done, but show e.g. 10 cycles improvement when no locking is done.
- The pipeline-overhead could be lower, but its not bad.

Resistance against open standards (almost everywhere)

2008-12-22T13:11:00.001-08:00

Disclaimer: This entry is full of half-facts and undirected sweeping swipes against all and everybody ... all this is only my personal opinion.
Furthermore I am I'll and have fever ... take everything with a grain of salt, please.

As you maybe have heard, JavaFX is bundled with ON2 video codecs. No idea who decided why to get this proprietary stuff into JavaFX. Even if ON2 is better than Vorbis - why not give users/developers the choice what to use?
After all, its just another proprietary codec - they could have used Vorbis based stuff without breaking any compatibility as far as I know.
Its like integrating just another binary plug, a plug that cannot be simply replaced by a community developed open-source version due to all the patent stuff. They did this after all the troubles they had with the binary plugs when OpenJDK was opened. Maybe the company behind ON2 decided to somehow pay money or share revenue caused by the success of their codecs boosted by JavaFX. Who knows.
I really like JavaFX, but looking at the video codec decision, I still doubt large companies are able to fully understand OpenSource. It isn't just a magical buzzword to increase your revenue.

Another example is Nokia - everything is well in their open-source universe as long as you don't dig deeper.
The bug with most votes is there since the 770 was released: Adding support for Ogg Vorbis audio playback to the device by default.
The N800 does support all the proprietary stuff like wma, real audio, mp3, aac ... but when MANY users ask for ogg the company is silent.
So what do users of Nokia's internet tablet get? They'll get support for Silverlight, I bet the stuff developed by Novell. Nobody opened a bug-report asking for silverlight support, but many asked for java support in the maemo-mailing lists.
Well, of course Novell's pushing of .NET into Linux doesn't have anything to do with their Microsoft deals.
And some former important developer now anxiously awaits advent of "his" technology conquering the linux world pushing it into Gnome. I doubt he will be celebrated anyway if that succeeds.

There seems to be a huge resistance against open standards, everybody likes squeeze money out of users, by not letting the users decide and forcing them into a format trap. And no, installing a WMA encoder with Windows by default is not choice in my eyes.
I am not against proprietary code, nor am I against large companies. I just would like to have the choice, and choice implies open standards.

By the way ... Merry Christmas :)

Almost Pure Java(2D)

2008-12-16T15:01:00.000-08:00

The last few days I ported (almost) all the XRender specific C code to Java, and although there are still some bugs left (e.g. it deadlocks from time to time) it works quite well:

All the functionality/features of the C based pipeline have been ported, except text rendering which is a dirty hack for now because I would need some data only available in native data structures by now.
So all the rendering is now done without JNI calls, resulting in ultra-low per-primitive overhead :)

Once all the stuff is working I guess its time for another cleanup ... however without structural changes ;)

Java-level protocol generation

2008-12-09T13:10:00.000-08:00

The last few days I was experimenting with xcb's new socket-handoff mechanism. It allows mixing self-generated protocol (java2d) with protocol generated by xcb/xlib (all the awt/motif stuff) - with a callback notifying the native side when it should give away control over the socket to the native libraries again.
I had quite a hard time with JNI, not knowing that local object references are only valid during the JNI interaction they were created for - but once that was fixed everything worked out quite fine.

The main advantages are no per-primitive JNI overhead and almost pure java - simplyfing maintainance and better portability as well as better performance.
Of course there are also disadvantages like dependency on a very recent version of libxcb (not in OpenSolaris for now) and maybe a higher protocol generation overhead due to java's managed nature.

For now only rectangles are supported, in the screenshot below the red rect was rendered by the "traditional" Java->C->libX11 call, and all other rects were directly generated in java:

JXRenderMark

2008-12-05T13:05:00.000-08:00

JXRenderMark:
I've released JXRenderMark-0.6, a XRender benchmark written in C which stresses functionality the pipeline depends on. The idea is to be able to show acceleration problems with the benchmark rather than having to build one-time testcases for each incident.

source, binary and results can be found at:
http://78.31.67.79:8080/jxrender/RenderMark.html

Update:
JXRenderMark-0.6 has been integrated into the phoronix benchmark suite :)

NVidia Driver:
NVidia released the second release of the 180.* beta drivers. This release is impressing, especially with the fixes I did last week to the pipeline.
Almost the whole Java2Demo is accelerated, with the only exception of Gradients - all animations just fly :)
A Lightbeam-Nimbus run takes 6200ms, 5200 when I disabled gradient rendering in the pipeline and 4700 with Mask*-Operations and Gradients turned off.
Hopefully Gradients will soon be accalerated, and not only for GF8+ but also GF6/7.

Offscreen pixmaps:
Offscreen-Pixmaps in the X11 pipeline are no more, if you're running on an EXA based driver.
I've written a patch which disables them in the case java is running local and SHMPixmaps are not available, to avoid the 5-10x slowdown linux users were experiencing after distributions defaulted to EXA.
Better no accaleration than some. Will be in JDK6u12 :)

IcedTea6 integration

2008-11-30T12:38:00.000-08:00

IcedTea Integration:
Thanks to Mark Wielaard, the XRender pipeline has been merged with IcedTea6 [link].
The pipeline will be built by default, but disabled at runtime, to enable it simply pass -Dsun.java2d.xrender=True.
This way the pre-rewrite version can be used as driver-testing vehicle, hopefully it will lead to stable and fast drivers.

Small enhancements & bug-fixes:
I've just pushed a new version:
* Optimized line-rendering, not triggering fallbacks on GPUs without A8->A8 composition support.
This should be only relevant for i830 (everything smaller than intel-915 chipsets) as well as GeForce6/7.
* Fixed a bug which caused an unescessary mask copy at every non-solid operation (e.g. paints, or translucent colors). For some Java2Demo's this improved performance a *lot* :)
* I've fixed a bug Mark found, where I'd mixed up xrender and x11-pipeline initialization.

JGears2 / RenderMark

2008-11-21T05:48:00.001-08:00

1.) JGears2, a simple Java2D shape rendering benchmark (Zack Rusin's QGears2 ported to Java) is available on the project page.
You can give it a try using Webstart.
Update: Somebody else did the port almost simultaneously, and his veryion even implements the "fance" mode: http://trac-hg.assembla.com/jgears/wiki#Java2D
Well, this clearly deprecates my version ;)

2.) I am currently developing RenderMark, a simple XRender benchmark written in C. It test the areas the pipeline uses heavily, to allow driver/xorg developers to find regressions and optimize their drivers for our type of workload.
A first version, only testing geometry processing, can also be found on the project pages.
Hopefully it will help AMD to optimize their drivers, and will be integrated into the phoronix unix benchmarking suite.

3.) Google decided to build a new datacenter located 2km away from my home. Strange ;)

4.) Today I got Catalyst-8.11 working on my HD3850.
As I suspected its almost software-only - so results are not bad, but also not that good.
Lightbeam/Nimbus took 9300ms vs. 15500ms with the X11 pipeline, and 6800ms with the NVidia driver.
However the nvidia driver hit fallbacks, so once these issues are resolved things should be even better.
By the way, the Radeon does the job in 4000ms on WindowsXP with the D3D pipeline - thats definitivly where I would like to be after the rewrite (and with useable drivers!)

university practical

2008-11-17T12:38:00.000-08:00

1.) I am currently trying to find a professor who accepts the xrender-pipeline-rewrite project as university practical. It seems to be a problem that the pipeline does not fit well in an institute's sector, because it covers many fields but nothing in depth.
So if a professor of TU or university vienna is reading this ... ;)

2.) I gave the LightBeam/Nimbus benchmark another try with the new 180.06 Beta-drivers on my GF6600.
XRender: 6800ms / Software: 7600ms / X11: 16000ms

Although there are still performance problems left (we depend on solid operations on A8 destination, but for now the binary driver doesn't support it for GF6/7), the new pipeline is already faster than software-only.
And this was on a single-core CPU, so no benefits because X & java running simultaneously ;)

The new beta release also disables SHMPixmaps by default now, explaining the bad performance of the X11 pipeline. So there are not many drivers left supporting SHMPixmaps - I guess soon Linux users will start to complain about low performance of swing interfaces.

KDE4.1 rant

2008-11-09T01:12:00.000-08:00

I am a long-time KDE user, and always enjoyed the high functionality and pretty good UI performance of KDE3/QT3.

Since KDE-4.0.1 I try KDE4 based distributions from time to time, and I am quite unhappy.
What really hurts is that QT4's window-redrawing is as slow as GTK's, maybe even slower - even if trolltech advertises it as x-times faster.
Furthermore it seems design and eye-candy has (had?) higher priority than functionality - a lot of common stuff is not implemented or doesn't work as expected. They even maintain their own HTML engine, but are not able to get the basic desktop right.

KDE-3.5 is phased out by many distributions, so I'll have a look at Gnome. However I hope the gnome project will go different ways than its founder and innovate instead of just cloning others technologies.

After so many harsh words, I would like to say thanks to all who made linux on desktop reality. My discomfort with KDE4 is only caused by the high standards (your work) I've become used to in the past.

ATI - Catalyst Linux Drivers

2008-11-05T14:14:00.000-08:00

I recently tried ATI's Catalyst 8.10 driver to see how well it accalerates XRender on my Radeon HD3850.

To be honest it was quite a disappointment:

RENDER accaleration has to be enabled manually, using the Textured2D/TexturedXRender
Locks up on my machine immediatly w/o those options.
Other users report screen corruptions when enabling TetxuredXRender, overall it does not seem to work very well.

I really like AMD for releasing their specs, but when it comes to drivers they are currently last.
Novell developers paid by AMD work on RadeonHD, which doesn't provide accaleration of R600/700 (HD2/3/4) and R500(X1x00) accaleration is just copy&paste from the open-source radeon-driver.

Their propietary driver doesn't do well at all for 2D accaleration, at least what I have heard and experienced.
So for now their is no useable RENDER accaleration for ATI's latest GPU generation (released in 2006), not by the closed-source one, and not by any existing open-source driver.

I opened a (rather lobby-oriented) bug-report: http://ati.cchtml.com/show_bug.cgi?id=1338
Would be great if you could post a comment and show that there are users who care about 2D accaleration, and not only 3DMark points.

Precompiled packages available

2008-10-24T03:28:00.000-07:00

I've built precompiled packages as well as revised the project pages a bit.
Both are available for x86: http://78.31.67.79:8080/jxrender/

I would be really happy about feedback, especially how it works on different hardware.
There's quite a lot of hw untested (see "Driver Status"), so if you have an untested card with recent drivers it would be great if you could give it a try and report back wether it worked and which bugs you've run across.
Feedback over Mailing list is preffered, or simply leave a commend here.

TransformedBlit rewrite (and new benchmarks ;) )

2008-10-22T09:11:00.000-07:00

TransformedBlit rewrite:
TransformedBlit was one of the most ugly parts of the pipeline and had negative influence on its performance, so I finally sat down, tinkered a few days and rewrote that stuff.
Its far from perfect and the coding-style is even uglier than before, but image-interpolation is now done the same way as Java's software pipelines do and performance improved especially for not accalerated composition.

I did this before the pure-java rewrite to be able to test against different drivers, so at the time the rewritten pipeline is done drivers are in a good shape.
I'll soon start to distribute pre-built OpenJDK packages containing the pipeline, it would be really great if there would be interest in testing it.

Swing Benchmarks:
I recently compiled xorg-server-1.6/intel from GIT. Intel seems to fight with some performance regressions because of their gem-rewrite (I only tested on a non-GEM system), with some workloads I saw halfed throughput, however there have been enhancements in the X-Server I was interested in:

"Nimbus - Metal" -> "Lightbeam - Metal"

The good news is that the XRender-Pipeline(XR) beats the X11 pipeline for this specific workload in every case on every accaleration architecture (EXA/XAA) on my system.
The bad one is that the pipeline is still faster on XAA than on EXA.
This could have to do with the performance regressions in the intel-driver mentioned before, but I still doubt that EXA will beat XAA even once they are fixed.

My theory why XAA is faster than Software is that my dual-core cpu is able to benefit from the additional asynchonizity brought by the client-server design of X.
While the X-client (java) is able to run nimbus/pipeline code on one CPU, the xserver can run its software rendering loops on the other core.
The Software-Pipe is synchronous however, waiting until a software-rendering operation has finished.

After all, once the GEM rework is done, I want EXA to beat XAA's result. I guess this means filing many performace bugs, like this one: https://bugs.freedesktop.org/show_bug.cgi?id=18075

Cool XCB improvements

2008-10-14T14:42:00.000-07:00

Recently there's a lot of interesting work going on in XCB, which is used indirectly by the XRender pipeline via Xlib.

1. Output Buffer enlarged:
In one of my last posts I complained that the output buffer was limited to 4kb, now the default was raised to 16k. Although I had hoped for some API-adjustable buffer size, thats way better than the 4kb and its furthermore adjustable at compile time. So chances are good that desktop distributions will set it to ~64k to squeeze out some additional performance for their users.

2. Socket-Hand-Off:
Beside the fact that this will improve performance a bit, this will allow applications to write directly to xcb's socket, instead of having to go through xcb's protocol generator. (as far as I've understood).

This would really be *extremly* helpful for the pipeline rewrite.
I would like to write the pipeline in pure java, but instead of going through JNI for each primitive I would prefer to buffer it, very much like the D3D/OGL pipelines do.
The new pipelines however have to generate an opcode stream which is later re-interpreted at the native side (somthing like switch(getNextOpcode(buffer))) - and without the socket-handof-mechanism we would have to do exactly the same.

With the socket-handoff stuff in place, it should be possible to directly write X11-protocol to a large (NIO?) Buffer, and when its time we flush that data directly through xcb's socket, which means:
- No per-primitive JNI cost
- No additional command-stream generation / interpretation
- The buffer is ours, so we can size the buffer ;) (really?)

One thing I am not sure about is how the IDs could be synchronized with xcb, like the IDs of server-side resources, hopefully there's a solution.

Well, for now ... university has me again *argh!*, and there are a few things I would like to fix in the old pipeline - in order to test dirver compatibility and submit bug-reports, before I can start working on that stuff.

NVidia 178.80 :)

2008-10-11T04:03:00.000-07:00

Finally the new NVidia drivers (178.80) went gold, and they are impressive :)
They perform extremly well over a broad range of RENDER operations and they don't seem to have any performance weaks the pipeline hits (except subpixel AA text on GF7 and below).
One bug which affects TexturePaints shows up in some Java2Demo's, but I guess this small problem should be fixed soon.

Furthermore, the git of the intel-driver now archieves 960.000glyphs/s on my 945GM, even without GEM, so text should no longer be a bottleneck for the swing benchmarks. Odly I am experiencing other slowdowns with this driver and I was not able to locate their reason - they are not caused by fallbacks, and a lot of time is spent in kernel. Maybe sysprof can help here...

Prebuild packages with the pipeline should be available soon, I am just waiting to get my vServer account activated.
Currently I am struggeling with the transformed blit rewrite ... hmm ... somebody with a good background about AffineTransformations out there? ;)

Driver bugs and software fallbacks

2008-10-04T07:11:00.000-07:00

A bug I repored to nvidia and intel driver developers some time ago seems to be harder to fix than I thought.
For composition where the source is read outside of its surface bounds, the result should be transparent (not touching the background), but instead its black for SRC, when src is a RGB24 picture:

In the short term both, intel and nvidia driver will fallback to software in this case because hardware does not seem to support it directly. I hope soon workarrounds will be implemented (in theory the driver would only have to allocate a ARGB32 picture, blit to that and use that one instead - maybe it could be done even more efficient with shaders). In the meantime I fight with building xorg from git ;)

Update:
Thanks a lot to Carl Worth for looking deeper into this issue! At least i965 and higher support the required behaviour and Carl fixed the driver, I filed a bug about it on 915 and lower. There are workarrounds which would solve it on that hardware too (if there should really be no support for it), however they are more than a 1:1 mapping and only apply in special cases. Using a temporary ARGB32 surface (maybe with tiling for very large source-pictures) is somewhat inefficent but should solve all cases.

JVM improvements:
A lot of interesting stuff is happening in the JVM space:

- The new G1 "Garbage First" garbage collector has been open-sourced
- IBM's Java got a cache for JITed and AOT code, I hope Hotspot will soon have a compareable feature too.
- 64-bit client jvm is almost ready
- Tired compilers are working
- CompressedOops reduce overhead on 64-bit platforms, when heap < 32GB

No idea what will be ready for JDK7, but this definitivly will be an interesting release again :)

OpenJDK Challenge Results

2008-09-30T11:15:00.000-07:00

Finally the waiting is over and the Challenge winners have been announced, Congratulations to all winners!
The projects are really cool and I am quite curious to see how they will evolve.
Of course I was quite suprised that the XRender project has won the Gold Medal :)

Thanks a lot to Dmitri Trembovetski who supported the project from the very beginning by offering to act as contact point, who was always patient and very helpful ... and even had a minute or two to talk about non technical stuff :)

Thanks of course also to the 2d-dev team who, especially in the beginning, tolerated all my neverending newbie questions and all people involved in the Challenge.
And last but of course not least thanks to Sun for open-sourcing java and for sponsoring the challenge.

Of course I'll continue to work on the project and that is what I hope will happen in the short term:

Build binaries so that its easy to test it without spending a day (or two^^) compiling and patching OpenJDK. If your intention is using ordinary Swing apps with Ocean LnF your chances are good to see really good performance even with the current drivers :)
Implement some outstanding optimizations and fix remaining bugs.
Test on Xorg git to see if showstoppes and performance problems are present, test as much hardware as possible and report all bugs. Goal would be to have infrastructure available which is able to run the Xrender pipeline really well.

After so much excitment its time for a cold beer and StarTrek ;)

NVidia Driver Bug

2008-09-24T11:03:00.000-07:00

Finally I was able to hunt down the bug that caused ugly artifacts with the new NVidia beta drivers, things like this:

It seems to be a race-condition in the driver, if we do something like this (however that would work, because we would use another, optimized code-path which doesn't trigger the bug):
g.setColor(yellow); g.fillRect(); g.setColor(red); g.fillRect();
It seems the driver doesn't make sure the setColor really finished before it starts with fillRect, so it could be that the second rect is not red, but also yellow.

http://www.nvnews.net/vbulletin/showthread.php?t=119910

Hopefully all that bug-hunting will soon lead to good drivers ;)

Update:

There were some doubts wether Xorg's software implementation is correct, as it differs with what the Intel driver currently does I filed a bug some time ago. Luckily the Intel driver will follow the software implementation, the Radeon driver already does as far as I know.
This change means that we can implement transformed blits a bit more efficiently, if no filtering is requested.

http://bugs.freedesktop.org/show_bug.cgi?id=16820

Java Gears

2008-09-24T07:40:00.000-07:00

To be able to compare the XRender pipeline's performance with other Libraries like QT or cairo, I ported qgears2 (a port of the original cairo-gears program to QT4) to Java:

Sure, its nothing to rely on, but at least a nice demo and at least gives some indication where we are when it comes to shape rendering.

QGears2:
EXA: 32/85 (No AA / AA)
XAA: 120/100

Java Gears:
EXA: 220/60
XAA: 200/82

So for aliased rendering Java running the XRender pipeline is quite a good deal faster, but we are behind when it comes to antialiased rendering.
I guess a large amount of cycles accounts to xlib/xcb, we hit 17500 context switches per second, I filed a bug about the problem discussed recently: https://bugs.freedesktop.org/show_bug.cgi?id=17735
This was on Xorg-1.4.99.05, so the EXA results are influenced by some performance problems that version has.

I'll have to ask zack, if he agrees source will be available soon.

Mask upload performance

2008-09-22T13:53:00.000-07:00

Antialiased rendering is currently done by uploading mask-tiles to the XServer followed by a composite operation with that mask.
Beside the fact that performance is not very good compared to the D3D pipeline, I saw an awful high context switch rate running J2DBench demos like lineanim (30.000/s) which is ... well ... not pretty.

* The problem is that xlib/xcb's buffer is only 4kb small (it has been 16kb by default in the "old" xlib implementation), and a AA tile is between 0-1kb large, so after maybe maybe 6-8 tiles the command-buffer is flushed, which results in a context switch. The ugly detail here is that its not possible to adjust the buffer size at runtime, not even before startup (was possible with old xlib) or compiletime, hopefully this will change.
* Another performance limiter is that the mask-data has to be copied using the command-buffer, over unix domain sockets to the XServer.

Xorg supports the Shm extension, however earlier benchmarks I did show the penality for having to wait until the XServer has copied the data before the shared memory region can be used again.
The X11 pipeline also does Shm transfers only if the amount of data to be transferred is >=64kb, otherwise its not woth the additional round-trip.
One roundtrip for 1 tile is way worse than one flush for every ~7 tiles of course.

The solution could be using more than 1 shared memory segment, and only Sync when all have been used, I did some benchmarks and the result looks promising.
Uploading a 32x32x8 mask 10.000 times and doing a composition operation with it, takes:

So when using 4 shm masks, and syncing after those have been used performance is the same as when using the traditional mask-upload-path. 1 mask consumes about 1kb for the pixmap and 1kb for the shared memory area + all the overhead associated with it, so it should still be no problem preallocating 32 or even 64 masks.
Allocating one large pixmap and maybe also shared memory area maybe reduce the overhead.

The cool thing is that this code does force round-trips by syncing, however Xlib provides a event-based system which notifies the client when image-transfer was completed - which should make the shared-memory approach even faster.
So for now I see a 2x improvement for the upload path, for sure this will speed up antialiased rendering quite a bit, I am quite curious how much.

Update:
In the benchmark above I only tested Xorg-1.3/XAA, I repeated the tests with Xorg-1.5 and EXA:

Xorg-1.3/NVIDIA: 80ms (tested on my old 2.6ghz/P4 notebook)
Xorg-1.3/XAA: 85ms
Xorg-1.3/EXA: 1000ms
Xorg-1.5/EXA: 250ms

So EXA seems to struggle a lot with that kind of workload :-/
Although a lot of time is spent in dixLookupPrivate, it only accumulates to 20% of total runtime. I definitivly need to build Xorg-Master and see how that performs.

NVidia does quite well, although this was an old legacy release. Looking at oprofile it seems to be done in hw, almost no time is spent in libfb :)
Also, the old Laptop still used traditional XLib, and a little disappointing result is that using SHM or not does not seem to make a lot of difference (>10%) there - so maybe using SHM in this case is just working arround Xlib/XCBs problems.

Laptop repair

2008-09-09T10:54:00.000-07:00

Soon my Laptop, a Toshiba Tecra A8, will be on its 4th "vacation".
I tend to do all my work on a Laptop so I bought a model which was praised for its mechanical stability and durability. I guess those beasts simply are not built for my type of "workload", so like all its predecessors it needs frequently repairs.
I'm glad that 2 to 4year warrenty extension was so cheap and support is quite ok.

OpenSolaris support will have to wait until I live in vienna again, I simply don't get it working. I also plan to create some pre-compiled binaries, so people can test the pipeline without compiling OpenJDK itself.
I also would like my Deflater/Inflater improvements to get in OpenJDK, but I guess I have to get used to the code again and write some tests to verify it.

NVidia Binary Driver 177.70

2008-09-01T15:25:00.000-07:00

NVidia has released a few small bugfix-releases following 177.67, and I gave the 177.70 beta release a try.
Their proprietary driver is especially interesting because it does not depend on EXA (which still has some performance bugs in xorg-server-1.5) and all the memory manager stuff is already in place.
Most Java2Demo tests are accalerated really well now, however the driver seems to struggle with text so nimbus-performance is worse than with the Nouveau driver.
Another weird thing is a software-fallback hit in Java2Demo when using TexturePaint, which I was not able to reproduce with J2DBench at all.

More about it here: http://www.nvnews.net/vbulletin/showthread.php?t=118801

Despite the problems reported NVidia is definitivly doing well.
Hopefully the problems will be fixed in the next few releases, enlarging the types of hardware the XRender pipeline can run on well.

OpenSolaris

2008-08-29T15:03:00.000-07:00

My train-flatrate ticket will expire soon, so I'll take another trip to vienna downloading a new OpenSolaris build tomorrow.
I haven't been very successful with 2008.05 (it does not even boot on my laptop), hopefully newer versions will work smoother.

Update:
Build95 seems way better than 2008.05. The package-manager worked out-of-the-box, the new shell seems to be bash-compatible and changing the desktop-resoltion no longer crashes the system running in VirtualBox.

However it fails building OpenJDK, as far as I can see the SunStudio compiler dies:

CC: Fatal error in ccfe: Killed
sun.font/fontmanager/obj/CursiveAttachmentSubtables.o Error 1

Hopefully this is a known problem, with a known workarround, because it starts to become frustrating.

NVidia Binary Driver 177.67

2008-08-19T10:32:00.000-07:00

NVidia driver improvements:
Today NVidia made a new beta-driver available, adressing many of the performance problems I saw when running the XRender pipeline on my GeForce6600 using the proprietary drivers - caused by the quite limited Render accaleration.

Taken form the release notes:

Improved support for RENDER masks, as well as RENDER repeating modes and transformations, for video memory pixmaps.

I haven't tested for now, but this should mean nimbus should run quite well using the proprietary drivers.
They are especially interesting because they don't suffer from some EXA performance problems I am experiencing, I am quite curious how they will perform :)

Another statement taken form the release notes:

Added an 'AllowSHMPixmaps' X configuration option, which can be used to prevent applications from using shared memory pixmaps; the latter may cause some optimizations in the NVIDIA X driver to be disabled.

So it seems time has come for SHMPixmaps to go away. EXA already removed support for SHMPixmaps (which hurts the X11 pipeline quite a bit) and the NVidia driver seems to go the same route.

The interesting thing is that those features were done because of the preassure generated by the community for better performing drivers - at least thats my impression.

After all, I am also curious what will be done about the proprietary AMD driver.
For now it still relies on XAA, and it seems AMD is the only major GPU manufacturer not providing drivers which are able to accalerate XRender properly.
Hopefull when RadeonHD is able to accalerate XRender well on the HD series, the proprietary 2D part will be removed and replaced by RadeonHD. Maybe the propiertary driver could be installed as add-on to RadeonHD, this would be my favourite distribution model.

Challenge:
The result of the challenge is still unknown ... wow I am quite nervous right now.

I hope that the missing Solaris support wasn't too negative as it should be fixable in a couple of days.
I ... well just forgot about it. What a shame, my stuff does for now (at least in VirtualBox) not run on the Unix of the sponsor :-/

Sharp edges..

2008-08-10T02:49:00.000-07:00

Benchmarks:
I did some further analysis why the swing-benchmarks (and some others) don't perform that well.
Of course there's still lots of room for improvements in the pipeline itself, but some Xorg performance bugs turned out to be show-stoppers here.
The updated benchmarks should be soon available at: ...

Blits / sharp edges:
Xorg-1.5 now supports RepeatPad (however Intel still falls back to software for now), which is needed to not get smeared borders when scaling images.
With some tricks the mask's rectangular geometry can be used itself to clip of the repeated edges (maps to GL_CLAMP), so we don't have to generate the rotated images geometry anymore :)

The following screenshot shows a rotated image with a 2px black line on its edges - sharp edges and interpolation inside the image ... as it should be:
.... :)

In theory it should be possible to use a 1x1 mask and simply adjust the scale to get the expected size - however I don't know how rounding errors could influence the result. Most likely I can use the existing mask-buffer pixmap and tile if the area is larger.

Over

2008-08-05T01:51:00.000-07:00

2 hours ago the deadline ended, 6 projects have been submited - wow there've been some really cool things happening over the past few months :)
Well now the challenge is over ... but of course the project will live on.

The next few days I'll be recovering a bit, I guess the only good thing about deadlines is that everything is just cut off after it.
Wait ... maybe I'll profile nimbus and fillrect performance before ;)

Update: After stubbing out all MaskFills, MaskBlits, Paints as well as transformed blits, performance improved by only ~18%, for the Lightbeam-Nimbus test published on the project-page.
The profile looks very similar to MigLayout's. Most of time is spent on the X-Server in glyph composition, so once the glyph enhancements are there also nimbus should benefit a lot :)

Also a stand-alone testcase shows XAA beeing twice as fast for 20x20 rects than EXA.

In general EXA seems to suffer at least with Xorg-server-1.5 a quite high per-primitive overhead, hopefully this is better when 1.6 will be released. For example for the 20x20 rect 10% of cpu time is spent in the driver, the rest in XOrg.

My goal would be to have all functionality required to run the XRender pipeline (with the image-scale fix in place) accalerated in xorg-server-1.6 as well as intel-2.6.

Solaris...

2008-08-04T15:59:00.000-07:00

I finally got the XRender pipeline to build on Solaris, however it does not work correctly on my installation in VirtualBox on the local X-Server. It does work however if I re-direct it to my X-Server running on Linux.
I need to get a "real" Solaris installation soon and fix it, I am a bit ashamed it does not work :-/

Solaris, Radeon HD3850

2008-08-02T13:38:00.000-07:00

Recent progress:
The past few days I worked further on the project-page (will be online soon), fixed some bugs and continued to work on get it on solaris building.
For now it fails at linking-stage, I don't know but the linked complains it can't find a symbol located in libmawt.so, when linking libfontmanager.so. The same stuff works on linux :-(

All the code is in the repository, so if you are curios give it a try :)
Just build it and specify -Dsun.java2d.xrender=True at the command line, and highest graphic performance will be yours ;)

Radeon 3850:

I also bought a Radeon HD3850, the card was extremly cheap, probably because its sold out in favour of its 4850 successor - its a nice upgrade for my brothers computer and gives me the opportunity to test against the RadeonHD driver.

This means I can test the following hardware-driver combinations at home:
Nvidia: proprietary / nouveau / nv (uninteresting)
AMD: RadeonHD / radeon (on RV420) / propietary (uninteresting)
Intel: 945GM

Maybe a collection of IGPs like VIA chrome or sis GPUs would be nice to have, I hope I can find some testers :)

Building on OpenSolaris

2008-07-31T16:49:00.000-07:00

Today I installed OpenSolaris-2008.05 in VirtualBox, took some time but works quite well.
Bridging the network to allow Solaris to download the Sun-Studio compilers took even more time and making OpenJDK build ... well ;)

1.) You need both gcc and Sun-Studio compilers
2.) You'll need cups-headers, in package SUNWcups. If "pkg install SUNWcups", can't find anything, run "pkginstall refresh" first
3.) If compiling the freetype-test fails with some cryptic relocation errors, install SUNWtoo
4.) If it bails out because it can't find sys/audio.h and other stuff, install SUNWaudh (this is not sanity checked).
5.) Install X11 headers (also not santity checked).

If you don't know how the package you need is called, just do
pkg search -lr file_contained_in_package
to get a list with packages containing the file.

Well, at least I can now also compile the hibernated patches on Deflater/Inflater after the challenge, don't know if I would have gone past this just for those patches ;)

Update:
Just tried to re-boot because I got some strange error messages when I shut the system down.
Well at least I know now that I should update the whole system when installing SUNWtoo. ARRG!

Yet another Intel driver bug

2008-07-30T18:35:00.000-07:00

1.) Today I had a great idea how transformed images could be implemented *efficiently* using XRender once RepeatPad is implemented and accalerated.

The main problem was the need to generate the geometry of the transformed image to clip away the PAD surrounding the image (GL_CLAMP).
However if a mask is used with the same size of the source-image (or a larger mask with clip-rectangles) and filtered with nearest, this already represents the final geometry.
If a mask with the scaled size is used and billinear filtering, I guess it could be used for implementing antialiased image rendering.

2.) Today I discovered the 3rd intel-driver bug:

On the top you can see how the result should look like and on the bottom how it actually does look ;)
The problem is that if a mask has a transformation set, its clip-rectangles are ignored.

Of course I'll test it on nouveau tomorrow ;)

Documentation

2008-07-30T13:54:00.000-07:00

The last two days I was working on cleaning up and re-formating the existing code and writing documentation.

Furthermore I've installed Fedora9 on an USB stick, so I can test the open-source nouveau driver on my brother's computer. It works suprisingly well, I've seen no artifacts running SwingSet2 with Nimbus :)

Tomorrow I'll travel to vienna again and try to get my code compiling and working on OpenSolaris.
I'll also start benchmarking - I almost forgot about an area where the XRender pipeline should shine :)

Java2Demo is not a benchmark

2008-07-28T10:12:00.000-07:00

Today I replaced lock/getrasinfo/unlock with one single call to XPutImage (no shm support for now), to get rid of some unescessary overhead for MaskFill.

To my surprise the LineAnim demo got even worse on Xorg-1.5, and according to top Xorg was using ~50% and the java-process 150% of my CPUs, which made me remember I saw similar things with the X11 pipeline when Java2Demo's delay was set to 0. Setting it to 1ms, the demo jumped from 150fps to 250fps, and now java was using 90% cpu on the line with xorg.
I don't know exactly what the cause is, but I guess its some locking problem in Java2Demo or Java2D itself.

I wrote a small benchmark drawing 10000 antialiased lines with a with of 100 and y1/y2 difference between 0 and 100, here are the results:
X11/Xorg-1.3/XAA : 1050ms
XR/Xorg-1.3/EXA : 1250ms
XR/Xorg-1.3/XAA: 1350ms
XR/Xorg-1.5/EXA: 1500ms
X11/Xorg-1.3/XAA: 15500ms

The X11 pipeline performs quite good on XAA, most likely due to using SHM (maybe even shm pixmaps), and Xorg-1.5 is slower than Xorg-1.3 most likely due to a performance bug I've already reported in a different context.
On Xorg-1.5 the profile looks for now like this:
72584 9.7587 Xorg Xorg dixLookupPrivate
51372 6.9068 libdcpr.so libdcpr.so writeAlpha8NZ
47983 6.4511 libdcpr.so libdcpr.so processSubBufferInTile
39541 5.3161 libc-2.8.90.so libc-2.8.90.so memcpy
32230 4.3332 libmawt.so libmawt.so prepareMaskPM
31531 4.2392 intel_drv.so intel_drv.so i915_prepare_composite

So after the dixLookupPrivate issue is resolved I guess performance will be better than Xorg-1.3 :)
I am quite curious how much SHM can help here.

Update:
Well of course using shm-images for MaskFill was a stupid idea, because it forces MaskFill to sync with the server every time, however I still found a small optimization to not unescessary copy data arround.
I guess a bit larger xlib-buffer-size would quite help here, but as far as I know its for now hardcoded to 4kb and can't be changed (for xlib-xcb).

MaskFill again

2008-07-26T01:59:00.000-07:00

Yesterday I had a cool idea about MaskFills, which are currently not as fast as I would like them to be ;)

Although the mask-upload-path for now is far from ideal (however this can be improved), a lot of overhead is caused by the fact that only 32x32 (or smaller) large tiles are processed, one after another.
So there is significant overhead setting up all the composition parameters for such a small operation - however I hope that drivers will also improve in that area.

One idea would be to use the mask-buffer-composition-tile, which currently is 256x256 by default. The small tiles could be shmput'ed to those mask and with a single composition operation (or more if the area is larger than the tile). The worst case would be again a diagonal line - where a lot of empty space would be composited - however, even in that case I think the new approach would be significant faster.
The fewer composition operations should easily compensate the wasted fillrate.
My goal would be 250-300fps in the LineAnim Java2D test.

So that would be one cool thing to do next week, if I won't get flooded with enhancement requests from the j2d guys ;)

Jippie :)

2008-07-25T15:21:00.000-07:00

After a long fight with mercurial over the past two or three days, its finally done: The code resides its mercurial repository, this is the initial changeset:
http://hg.openjdk.java.net/xrender/xrender/jdk/rev/6d294fa2bd42

Thanks a lot to Dmitri for his help and neverending patience ... I'll re-read the mercurial docs, I promised ;)

Thanks to flick-user rileyroxx for the nice photograph

Its still very proof of concept, and has many quirks I would like to change before the deadline, however I guess there are even more problems I don't know about ;)

I guess this weekend I'll have a break, my laptop feels quite burned out ;)

Vienna

2008-07-24T10:19:00.000-07:00

Today and tomorrow I am in vienna, I've a free train ticket which lasts two months.
My internet-connection an home is extremly expensive ( http://www.aon.at/ ), I'll change to an UMTS connection soon.
Hopefully the mercurial stuff will work out fine, and soon the xrender pipeline will on its place ;)

Today I did cleanups, removed tons of warnings from the native code and did some small fixes, but nothing exciting.

Benchmarking again...

2008-07-23T07:38:00.000-07:00

MigLayout Benchmark:

Again I could not resist benchmarking my pipeline when I remembered the MigLayout benchmark.
I used it a few years ago to proof SWT's poor performance (inherited from GTK+), and I think its a quite good swing benchmark.

These were the results I got:

	Nimbus	Ocean
XRender/EXA	2100ms	1000ms
X11/EXA	8000ms	5800ms
XRender/XAA	2800ms	750ms
X11/XAA	2600ms	800ms

The X11 pipeline is really fast when using XAA, because if something falls back to software it can directly manipulate the target pixmap using shm pixmaps.
On EXA however pixmaps are stored in VRAM, and shm pixmaps are not supported - the sysprof profile is completly dominated by moving data from/to VRAM.

The real suprise was how well the XRender pipeline does when running on XAA, and how little EXA helps when running nimbus. However Xorg's profile looks quite well and top says a lot of time is spent in the java-process itself (65% java, 30% Xorg), so either I am using JNI too much or some validation/transformation stuff eats up all the cycles.

Ocean on EXA spends most time in gradients and text, at leats text will improve a lot once owen taylor's glyph patches are in Xorg.

Update:

I profiled my pipeline running the benchmark and only little time was spent in the pipeline, so I ran the same benchmark on my brother's computer (Sempron64 1.8ghz, Geforce6600, WinXP, ForceWare 9371 driver):

	Nimbus	Ocean
Linux/X11	4400ms	800ms
Linux/OpenGL	6535ms*	--------
Windows-D3D	4800ms	500ms

* OpenGL on Windows did not work at all with fbobject=true, and got stuck after 5s with fbobject=false.
* OpenGL on Linux showed artifacts, and became slower each run (6535->33000ms). Latest nvidia binary driver was installed.

The benchmark seems to stress Nimbus in a way it doesn't like, no matter which pipeline was used.
I am totally impressed by the ocean result running on D3D, keep in mind this CPU is ~50% slower than mine.

MaskFill Performance:
Another topic I am not happy about is poor MaskFill performance.

	BezierAnim	LineAnim
All	175fps	150fps
no mask upload	300fps	200fps
no composition	300fps	200fps
nothing	750fps	440fps

I thought Mask-upload (XPutImage) would be the slow part because of using suboptimal uploading paths with quite some overhead and furthermore the x-server has to migrate data from sysmem->vram.
It showed up that composition (with a mask in vram) as well as mask-uploading (+migration) are both almost equal slow/fast.
Antialiasing relies a lot on MaskFill/MaskBlit (Nimbus), however I am not sure how much room for improvement is left - for sure it would help if the no-mask operations could be accumulated in the MaskBuffer, however for this an API-change would be required.

Rewrite

2008-07-22T14:58:00.000-07:00

Today I started the "rewrite" with the goal of clear seperation between the existing X11 pipeline and the new XRender pipeline.
It almost works as weel as the old "hack" pipeline, but some pieces are still missing and a few bugs did not dissapear suddenly as I had hoped for ;)

For now I won't create the "pure"-java pipeline I dreamed about a few days ago, its less than two weeks till 4th of August and I am not sure how much effort this route would take.
I'll try it out later with enough time to think about a clean design and an efficient implementation ... I am quite curious how well this design would play together with caciocavallo.

Driver bugs...

2008-07-21T15:30:00.001-07:00

Thanks to Dmitri, who suggested that both bugs I am experiencing are probably due to incorrect pixel/texel mapping. XRender itself is pixel-based, so the driver is responsible for the mapping.

The nimbus-corruption shown below is fixed in Xorg-1.5/Intel-2.3.2, however there is another bug where scaling on the x-axis only also blurs pixels on the y-axis when billinear filtering is used, and its still there in the setup mentioned above.
Switching to XAA (software scaling using pixman) did not show the problem.

Thanks again!

Nimbus

2008-07-20T12:42:00.001-07:00

After the gradient work I profiled Nimbus again and noticed there were still some fallbacks in action.
I had forgotten to register MaskFill primitives for argb-pre surfaces, and after adding those ... I faced the usual problems:
Note that they are not equally scaled, so in reality the size should be quite the same.
The two visual problems are the white area below the knob, and the different outline of the up/down buttons.
Also the gradient looks a bit different, I am not sure wether this is a problem in the pipeline or just XRender's different gradient implementation.

Overall performance is quite good now and with some planned enhancements for MaskFill (fast upload paths) it should be become even better, well at least something encouraging.

Nimbus seems to be an excellent "tool" for testing the more advanced features of the pipeline ... it seems there is no bug it does not catch ;)

Gradient performance

2008-07-20T10:57:00.000-07:00

Today I further investigated the performance problems when Gradients are used. Although its not really the the pipeline's fault something had to be done - even Metal/Ocean spent significant time drawing gradients.

The problem is how EXA does handle fallbacks:
For EXA the only concern is wether something can be accessed by the CPU or GPU, so if it has to draw a gradient which is pinned to sysmem (because gradients for now are not accalerated) it has to access the destination and mask surface with the CPU, because composition is done in software.
The problem is that for now the only way to make the surface CPU-addressable is to copy the content from vram to sysram - so mask and destination contents are copied from vram to sysram and composition is done by the CPU.
Now imagine what happens if directly after that e.g. fillRect is called. EXA realizes that this operation can be done by the GPU, but the image content is now in sysram. So it copies mask/dest pixmap to vram again, and the fills the single rect.

This made the X-Server spend more that 50% of its cycles in memcpy, most of the time reading back contents from vram.

The workarround for this problem was to allocate a 256x256 gradient-buffer-tile. So if a gradient would be used for composition it is drawn into this tile and then the tile is used instead of the "real" gradient as source.
The trick is that the tile-pixmap is never altered by the GPU, so the only copying is sysram->vram, once when the composition happens.

This workarround makes Netbeans-main-window-resizing a lot faster and also helps Nimbus which uses gradients even more. The drawback is once gradients will be accalerated, we will do a useless composition step - and the memory wasted for the buffer-tile.

Here are some benchmarks before and after that change:
BezierAnim: ~55fps -> 355-600fps
GradAnin: ~30fps -> 180fps

Netbeans...

2008-07-17T13:38:00.000-07:00

Sorry for the flood of screenshots....

I profiled it a bit running on Xorg-1.5 and for rendering about:
- 30% were spent in text-rendering
- 45% were spent in compositing (with about 30% spent in ram->vram migration caused by gradients)
- 2% were spent in lines (are unaccalerated unfourntunatly)

Not that bad, keeping in mind that text-rendering is currently heavily worked on, however I guess I have to work arround the horrible gradient performance.
Scrolling in the Editor is already feeling faster than with the X11 pipeline using XAA.

Better ...

2008-07-17T10:56:00.001-07:00

Today I found two bugs which led to the corruptions with Nimbus.
It looks quite well now, the visual differences are because I am running it on the OpenJDK7 codebase, maybe synth has not been updated in JDK7 to work with the ned Nimbus releases:

The first bug was when drawing images with transformations. The solution works (kind of) but is in my opinion very sub-optimal.
I am also fighting with something which could be an xorg-bug, I am not sure ... I prefer to blame my code before others ;)

Nimbus

2008-07-17T02:35:00.001-07:00

Nimbus:
Yesterday I started to make my pipeline work well with Nimbus.
The first test results were mixed - rendering was correct but performance was really bad.
The reason was that Nimbus uses translucent VIs, and I completly forgot to allow this.
Well performance is a lot better now, but the result is not that appealing:

The xorg-profile looks quite welll with the exception of gradients which are currently not accalerated.
EXA seems to move all pixmaps out of vram if a single pixmap cannot be migrated to vram, which leads to about 70% of xorg's time spent in moving pixmaps arround.
Even if they don't accalerate gradients in hw, I hope they will do better than that in future.

Xorg Bug or feature:
I am not sure, but I guess I ran into another Xorg-Bug - or its just a feature I don't see the use for.
In fact it makes my "life" quite hard :-/
http://thread.gmane.org/gmane.comp.freedesktop.xorg/30450/focus=30476

Artifact free Swing

2008-07-15T14:27:00.000-07:00

After quite a lot debugging I was able to find the cause of the swing artifacts.
The problem was that render also honors the clip-mask when a pixmap is used as source, of course this completly messed up the double buffering Repaint-Manager.

Now swing application look almost like they should:

(Boinc was crunching on both cores, so performance is not as bad as it seems ^^)

The last remaining piece to make common swing apps useable is copyArea, I hope I get it done in the next few days. There are also other annoying and serious bugs, but this one will make swing apps just work :)

After the most serious bugs I know about are fixed, I hope I can upload that "hack"-release of my pipeline to my OpenJDK repository, and start working on the final design.

Swing artifacts

2008-07-14T14:44:00.000-07:00

Today I was working on removing show-stoppers from the existing pipeline.
I also investigated the problem with the artifacts I see when running swing applications (unuseable, most components only paint at mouseover).
Although I still don't know whats causing this bug, but at least I know now where to start.
Clipping seems to be the problem, if I comment out clip-validation almost all elements paint properly - I hope I can find some short code to reproduce the problem.

Well here is s hort overview what has to be done for the "hack"-pipeline:
- Transformed blit (to be consistent with Java2D's rendering)
- Scale-quality adjustent (for now everything is smooth-scaled)
- Swing artifacts
- Extra alpha for mask and texture fills doesn't work
- CopyArea unimplemented

Of course there well be even more bugs pop up when I solve the problem with corrupted swing, but I hope that at the end of the week I can release a pipeline which works ok for most uses.
After this release I'll work on rewriting it, so that it can exist beside the X11 pipeline.

Rewrite in Java?

2008-07-13T15:33:00.000-07:00

Bugs and Glitches:
Well there are still some open issues I know about, and many small glitches which have to be fixed - however I hope that this will be done in the following two days and I'll start implementing the rewrite which hopefully will not be that ugly ;)

Rewrite in Java:
The current hack is more or less completly written in C (like the old pipeline), however with the mask-batchbuffer-work I actually realize how little interaction I really need with the C-libraries.
Some time ago I had an email conversaion with roman kennke about making the new XRender pipeline work with his java-only AWT implementation and the idea seemed really nice - however the way I started with the pipeline made it rather impossible.

In theory all I need to do is drawing lines and rects and playing a bit with dest and source parameters, in fact it would also make batching much more useful ... bringing the design closer to the STR approach again ;)

Well I still don't know wether I should go this route, the "deadline" is pretty close and any design mistakes could bring me way behind schedule. After all ... its only 3 weeks till then. If I could only have a little more time ;)

Line performance

2008-07-11T14:58:00.000-07:00

Lines:
After a lot of profiling and tuning line/draw performance is now quite ok, however for single diagonal lines the overhead is quite high.
I have some further ideas for optimizations, but I'll do them later - the project isn't really on scedule, so I'll focus on making things work ;) - and do those optimizations later.

The challenge was that EXA always ping-ponged the mask pixmap between sysram and vram, because it thought accalerating the fillRects() from drawScanline() is a good idea, actually it was a pretty bad one.
For now I have two masks, one I render the scanlines to and another for rendering the lines.
I render first the lines, blit the line-mask to the rect-mask, clean the line-mask with the same lines again but black-color and draw the rects to the rect-mask.
Sounds pretty horrible, after all this gave me best performance at the expence of one additional accalerated blit.
Its pretty hard to keep the line-mask in sysram (not even a fillRect for clearing the pixmap is allowed), after studying EXA's source I found it uses a "dirty" concept. If I use fillRect, the native surface is marked "dirty" and the next time a software-fallback happens EXA does a vram-readback ... well or somehow like this ;)

Yes this relies pretty much on expected behaviour, however it works also quite well with NVidia's proprietary driver - which is capable of accalerating lines. However, there is overhead of course.

Xorg-Bugs:
Well after those optimizations were done, it worked well on Xorg-1.3, but completly sucked on Xorg-1.5, because of the performance-bug already mentioned: http://bugs.freedesktop.org/show_bug.cgi?id=16647
and because of a new bug (so the report covers two regressions in fact),
A big thanks to Michel Dänzer who immediatly replied and fixed the second bug, and to Eamon Walsh for working on the remaining one.

Whats going on currently:
Well I am trying to fix all the stuff I know about, especially the thing where I know what causes the bug ;)
However, I still don't know where the swing-corruptions come from, maybe because copyArea is not implemented for now.

Well, here's whats going on for now:

Most of the Java2Demos work already fine, and with the hacks performance is ~ok.
I also worked arround some performance-bugs in Xorg when using Pictures without drawable, I simply don't use them anymore.
A kingdom for GL_LINE or however its called ;)

Whats next?:

Well after some finishing on the buffer-code, I'll try to get a clean pipeline implemented, that finally can be uploaded into the repositor.

fillOval performance

2008-07-10T03:59:00.000-07:00

Today I started integrating the mask-batch-buffer bits I wrote the last days into and did some benchmarking.

I tested with fillOval, because in the old pipeline it "simply" used XFillArc, whereas with XRender it is done by a general drawPath routine, so this should show how much the batching is woth:

	20x20	100x100	250x250	1000x1000
X11	2.44E7	1.44E8	3.7E8	1.92E9
XR	2.8E7	1.8E8	4.8E8	1.78E9

Except for very large ovals, the XRender pipeline is slighly faster, even in an area where the old X11 pipeline is pretty good. For lines and draw() I guess the picture will be different :-/
Using EXA or XAA makes no (large) difference, I guess the intel driver does not accalerate arcs/ovals anyway.

About Gradients and Traps...

2008-07-09T12:32:00.000-07:00

Radial and Linear Gradients:

Today I started Linear- and RadialGradients (that stuff that was introduced in JDK6). As far as I know LinearGradients are quite complete, Radial Gradients are still missing some functionality.
I guess the Gradient-Stuff is almost complete now :)

No more Traps!
Lines cause many troubles because Java relies on fast lines for shapes, however XRender simply does not support lines at all.
A line can be composed out of 3 trapezoids (and a huge amount of code and runtime-work is needed to get it done right), the traps generate a mask which can be used for composition - however thats really slow for something which is expected to be almost a no-op. For now there is not even a single driver which is able to rasterize traps in hardware.

While playing with the mask-tile-approach I had the idea to draw to my mask with Core-Drawing, which has support for pretty lines.
This would remove the burden of all those trapezoids :)
In theory it should work very well, in reality its not that bad - because EXA doesn't provide driver hooks for lines at all, but because traps aren't accalerated too, nothing is lost - its therefor as fast as the old pipeline on EXA.

The sad news is that its quite slow with Xorg-1.5, but worked ok on 1.3, and it really flies with the proprietary nvidia driver (I guess it has hw line accaleration).
I filed a bug-report, hoping that the situation can be improved.

I really hope I get the mask-tile stuff integrated soon, I am quite curious how it will perform.

Java.net Project

2008-07-06T13:25:00.001-07:00

Java.net Project:

I've created a java.net project, to allow participation and reviewing.
For now I don't use subversion, the "releases" are uploaded as tarballs - however I plan to change this soon.
The first release called "0.0.1" is really a development-only review, it will be completly rewritten soon so I recommend not wasting your time reading it ;)
The project-page can be found here: https://xrpipeline.dev.java.net/

Text benchmarks:
Last time I benchmarked, Dmitri asked about benchmarks done with J2DBench, however I was not familiar with it and only had a look at it recently. What a great and helpful tool :)

I've done some text-benchmarks with it, here are the results:

	Plain	AA	LCD
X11	561.758	42.955	41.678
XRender	148.757	134.761	95.184

Results are in chars/s with a 12pt font drawn directly to screen in 16-char blocks.
Currently there is some progress speeding up Xorg's glyph compositing, I guess with the patches it should be possible to reach ~500.000c/s for all three cases: Link

I did some other benchmarks and with the old "architecture" it seems text is really the only piece which is faster when a solid color is used. Although I expected some slowdowns, they were sometimes horrible :-/
Just another sign which underlines the need for the batched-mask-rendering approach.

Performance improvements

2008-07-03T11:52:00.000-07:00

Performance: Today I played with the ideas I accumulated over the past two weeks or so (already mentioned earlier) to improve performance of scanline based drawing, and implementing the "Extra-Alpha" concept with XRender.

The first attempts were quite frustrating, because performance was not near as good as I had hoped.
I ended somewhere in XOrg's software loops, spending 85% of total time in memcpy - which made me think FillRects to A8 is not accalerated by EXA or the intel driver (would have pretty much killed my ideas).
However it turned out to be a xorg-performance bug (at least as far as I can tell): https://bugs.freedesktop.org/show_bug.cgi?id=16600
Good to know about this limitation, maybe it can help improving the existing code a bit - thanks a lot to the guys at #xorg-devel for beeing that helpful and friendly :) (Still glad that I had not to fire up GDB^^)

The results where as pleasant as expected, for the micro-benchmark I ran before (filling 6250 spans, 250 at a time) I got:
Rendering to explicit mask using XRenderFillRectangles: ~10ms
Rendering to destination, compositing scanline per scanline: ~50ms

As always when using masks there is a worst case, a 45° line - however, as far as I can guess the low performance in the scanline-per-scanline case is not because of limited fill-rate, but from the per-operation overhead, which seems far lower with FillRectangles. I guess the worse the driver, the more the new approach "benefits" compared the old one - as long as it does accalerate FillRects to an A8 mask everything should be fine, with the exception of very old pre-3d-cards which are not really able to run EXA anyway.

Extra Alpha:
Another advantage of the new explicit-mask-approach is that Extra-Alpha can be done easily and is "for free" in the scanline/fillSpans case, in the line/path case there is one additional (usually accalerated) composition step compared to plain XRenderCompositeTrapezoids without extra alpha.

Over..

2008-07-01T13:47:00.000-07:00

- All exams are done, finally university is over and I can concentrate on my project.

- Rawhide (the development version of fedora) almost works ... using an old kernel its even able to run sysprof.
Performance is much better than with the Fedora8 based system I am running currently, however EXA still moves pixmaps arround like a mad cow.
I hope I can get a pre-release of the GEM intel driver working soon, so that I will be able to target the latest improvements, and not optimize for already dead code.

- I plan to create a java.net project where I will upload all code which currently exists. Well its mostly an unuseable hack, but I hope this will change soon.

Looking foreward to a few exciting (and hopefully not too short) weeks :)