RE: dist_texture status

Hi,

A few months ago David Thompson was kind enough to look through my log
files.  He discovered that an extra GL_PROJECTION matrix was being sent
across the wire with each frame; although this might not be the conclusive
reason for the framerate drop.  Below is part of the archived message:



-----Forwarded Message-----
From: David Thompson <[email protected]>
To: Jamison Robert Daniel <[email protected]>
Cc: [email protected]
Subject: Re: [Chromium-users] chromium 1.2 vs. 1.3 ... dist_texture SPU
Date: Wed, 05 Nov 2003 09:52:22 -0800

> ...
> The reason I believed it to be a disk access problem was that moving the
> frames to a SCSI drive increases the framerate, both with cr-1.2 and
> cr-1.3/1.4.  While the framerate is still slower with cr-1.3/cr-1.4, it
> did increase proportional to the increased drive speed.

> This is on a gig-E network.
Hmm, then the extra GL_PROJECTION matrix being sent over the wire
probably wouldn't slow things down... Have you tried using the npb
prefetch daemon? I haven't used it myself, but the idea is to have npb
contact a daemon running on the crserver node and load the next frame
into memory -- the kernel's cache would then be used when the crserver
requested the same file a short time later.

		David




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com