Samstag, 4. Oktober 2008

Driver bugs and software fallbacks

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 :)

Kommentare:

ijuma hat gesagt…

That is a good list of JVM improvements. I would add:

- invokedynamic
- Scalar replacement through escape analysis.

Some notes:

- Compressed Oops is already available in JDK6u6p (note the "p" for performance at the end). This means it will most likely be in JDK7 and possibly in a JDK6 update (I mean one without the "p"). The other question is when it will be enabled by default.

- I read that the 64-bit client VM would be available in JDK6u11 or JDK6u12.

- I seem to recall hearing that there's also a plan to have G1 in a JDK6 update release.

- Do you have any information on the status of Tiered compilation? I know that in some builds -server identifies itself as tiered in JConsole (e.g. jdk6u10rc with HS11.0-b15), but I am not sure if this is accurate because later versions of HotSpot say server again (e.g. jdk6u6p with HS13.0-b04).

Linuxhippy hat gesagt…

> - Scalar replacement through escape analysis.
Oh yes, I forgot this, thanks :)

I also wonder whats the state of stack allocation, I recall that it would be quite complex to implement ... and that its not clear how much it would gain.

Tiered compilers are already in JDK7 and work pretty well for many workloads: http://blogs.sun.com/fatcatair/

ijuma hat gesagt…

Yes, I know Steve Goldman was working on it and I was subscribed to his blog. However, unfortunately he is no longer with us and the last blog entry on the topic was in January. Based on that entry and the previous one from August 2007, it sounded like there were still many issues to be solved (in other words, it was not ready to be the default yet).

Ismael

Rémi Forax hat gesagt…

"Tired compilers are working"
^^^^^

And tired humans too.

ijuma hat gesagt…

Indeed. :(

Linuxhippy hat gesagt…

Did not know that Steve Goldman is no longer with us. What a loss...