Wednesday, January 12, 2011

historical mozilla-central git repository

A number of people use git to work with the mozilla hg tree. In the past I've wanted the entire history as a git repo so I converted the old CVS repository to git and put it up on people.mozilla.org.

You can set it up as follows:

git clone http://people.mozilla.org/~jmuizelaar/mozilla-cvs-history.git
git clone git://bluishcoder.co.nz/git/mozilla-central.git

cd mozilla-central/.git/objects/pack
# set up symbol links to cvs-history pack files
ln -s ../../../../mozilla-cvs-history/.git/objects/pack/pack-5b5d604ab48cf7bc2a6b4495292fa8700a987c5f.pack .
ln -s ../../../../mozilla-cvs-history/.git/objects/pack/pack-5b5d604ab48cf7bc2a6b4495292fa8700a987c5f.idx .
cd ../../

# add a graft from the last revision in the mozilla-central repo
# to the first revision in the cvs-history
echo 2514a423aca5d1273a842918589e44038d046a51 3229d5d8b7f8376cfb7936e7be810635a14a486b > info/grafts

Now you have a git repository containing all of the history. You can update the mozilla-central repository as you normally would. The conversion isn't perfect, but it's been good enough to have working blame back into cvs time.

Tuesday, January 11, 2011

Firefox acceleration prefs changing

I just landed a changeset that changes the names of the layer acceleration prefs in Firefox.

The old prefs were:
layers.accelerate-all
layers.accelerate-none

The new prefs are:
layers.acceleration.disabled
layers.acceleration.force-enabled

layers.accelerate-all previously defaulted to 'true' on Windows and OS X. Which meant that there was no easy way to force layer acceleration on if your card had been blacklisted for some reason. The new prefs allow the blacklist to be overwritten. The old prefs are not being migrated over to the new names. If you have a problem with the defaults, please file bugs.

Saturday, January 8, 2011

Trying out AVX

Intel's new Sandy Bridge CPUs came out this week and they support a new set of instructions called AVX. The AVX instructions are a much bigger change than the usual SSE revisions in the past few micro-architectures. First of all, they double the 128 bit SSE registers to 256 bits. Second, they introduce an entirely new instruction encoding. The new encoding switches from 2 operand instructions to 3 operand instructions allowing the destination register to be different than the source registers. For example:
  addps r0, r1       # (r0 = r0 + r1)
         vs.
  vaddps r0, r1, r2  # (r0 = r1 + r2)
This new encoding is not only used for the new 256 bit instructions, but also for the 128 bit AVX versions of all the old SSE instructions. This means that existing SSE code can improved without requiring a switch to 256 bit registers. Finally, AVX introduces some new data movement instructions, which should help improve code efficiency.

I decided to see what kind of performance difference using AVX could make in qcms with minimal effort. If you use SSE compiler intrinsics, like qcms does, switching to AVX is very easy; simply recompile with -mavx. In addition to using -mavx, I also took advantage of some of the new data movement instructions by replacing the following:
  vec_r = _mm_load_ss(r);
  vec_r = _mm_shuffle_ps(vec_r, vec_r, 0);

with the the new vbroadcastss instruction:
  vec_r = _mm_broadcast(r);
Overall, this change reduces the inner loop by 3 instructions.

The performance results were positive, but not what I expected. Here's what the timings were:
SSE2:75798 usecs
AVX (-mavx):69687 usecs
AVX w/ vbroadcastss:72917 usecs
Switching to the AVX encoding improves performance by more than I expected: nearly 10%. But adding the new vbroadcastss instruction, in addition to the AVX encoding, not only doesn't help, but actually makes things worse. I tried analyzing the code with the Intel Architecture Code Analyzer, but the analyzer also thought that using vbroadcastss should be faster. If anyone has any ideas why vbroadcastss would be slower, I'd love to hear them.

Despite this weird performance problem, AVX seems like a good step forward and should provide good opportunities for improving performance beyond what's possible with SSE. For more information, check out this presentation which gives a good overview of how to take advantage AVX.

Saturday, December 18, 2010

Improved Hardware Acceleration in Fennec

On Thursday night, after the all-hands party, Matt Woodrow landed a beautiful refactoring of our texture upload code. This should give a noticeable improvement in scrolling performance when accelerated layers are enabled and hopefully fixes some of the problems people were seeing there. It also improves texture upload performance on OS X.

Unfortunately, there are still two bugs that are keeping us from enabling accelerated layers by default:
Bug 619615 - Hangs on Nexus One
Bug 619539 - Startup crashes on Droid

Any help debugging these problems would be greatly appreciated.

Wednesday, December 15, 2010

Hardware Acceleration on Fennec

It's now possible with current nightlies to use OpenGL for compositing in Fennec on Android. To turn it on, go to about:config and set "layers.accelerate-all" to "true" and restart. If it's working you can go to about:support and the Graphics section will say "1/1 OpenGL".

It would be great if people can test it and let me know how it goes.

Monday, November 8, 2010

Dealing with mach_kernel in Shark

Sometimes when profiling a bunch of time ends up in mach_kernel. Figuring out why isn't always easy but here are two tips that should help a bit:

  • You can get better symbols for mach_kernel by downloading a KernelDebugKit
    This can help a bit when trying to figure out what's happening in the kernel. For example, _dtrace_get_cpu_int_stack_t becomes _mach_call_munger.

  • Shark has a System Trace profiling mode. This can show you what code is causing the kernel to do work. It can break down time by system call or by vm fault which should account for most things.

    While trying this out I noticed we were spending a fair amount of time in ChildViewMouseTracker::WindowForEvent(NSEvent*). This gave me the idea that the reason that Firefox causes the WindowServer process to start using a huge amount of CPU is because we tell the WindowServer to give us all of the mouse events instead of the ones only targeted at our window. Presumably this causes the WindowServer to build up a very large queue of events when the Firefox process is stopped and thus use lots of CPU. This turns out to be the case. nsToolkit::RegisterForAllProcessMouseEvents causes us to listen to all mouse events and disabling the code there fixes the problem. Bug 611068 tracks the problem.

Friday, May 28, 2010

Reviewing in vim

Bugzilla's review interface is poor. I find a mild improvement is possible by copying the review text into an editor and reviewing it there. One of things that makes this experience better is syntax highlighting. Here's a modification of vim's diff highlighting script that works with quoted patches. Adding the following to one's .vimrc will get it used for .review files:
au BufNewFile,BufRead *.review setf review