From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <14ec7b180811301754i36d6b1excea42d5bef38e8bd@mail.gmail.com>
Date: Sun, 30 Nov 2008 18:54:50 -0700
From: "andrey mirtchovski" <mirtchovski@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
In-Reply-To: <a717f060c03254f73746162ae4c37fe0@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <d1c554290811301554y58ba0e70m8c5a023d9b59915c@mail.gmail.com>
	<a717f060c03254f73746162ae4c37fe0@quanstro.net>
Subject: Re: [9fans] image/memimage speed
Topicbox-Message-UUID: 5413df18-ead4-11e9-9d60-3106f5b1d025

can you report timings on the xscreensaver hacks (link at bottom)?

they have a "benchmarking" option -b S which lets you see how many fps
they're doing:

mk all; for (i in 8.*) { echo -n $i^': '; $i -b 5 }

would run each hack for 5 seconds and let you know what their fps is.

i used to get incredible fps reports in parallels, where everything
was in memory and read backs were fast.

andrey

http://mirtchovski.com/p9/xscr/xscr.tgz

> i think this is a good point.  reading from the frame buffer can
> be deathly slow on a lot of modern video cards.  you're seeing a
> factor of 60.  it might be a good idea to keep a copy of the
> framebuffer in kernel memory.
>
> i have been using a write-combining framebuffer for about four
> months.  (implemented for the x86 architechture via the pat
> bits in the page table.)  it has made drawing (writes to the
> framebuffer) much faster, but, since reads from the frame buffer
> are slow for different reasons, it doesn't help at all for operations
> like unhiding windows.
>
> - erik
>
>
>