Friday, December 25, 2009

x64 fractserv test

project: 64-bit test.frp
server: eng-wzengerle64 running 64-bit version of fractserv, verified x64 native, all cores 100%
record, all frames empty with nearly identical coords, server Progress checked
server render times:

83.068
83.551
84.411
84.393
84.131
84.420
84.337

32-bit fractserv, also on eng-wzengerle64, verified x32 server render times:

84.572
87.800
83.241
84.129
82.974
83.261
83.002

Incredible, but for GMP 4.2, x64 appears to confer essentially NO advantage. WTF?

Saturday, December 5, 2009

canceling deep zoom render is too slow

Too slow as a minute or more to cancel in some cases. This makes normal navigation impossible.

TerminateThread seems to work fine, except it leaks 4K (per render thread) each time. No doubt it's stack-related. The leak adds up fast and judging from the net there's no way around it. Not a good solution, and dangerous too. What other options are there besides moving the cancel test into the x-loop?

benchmarks: test2rec.frp default image, deep zoom

pass # y-loop x-loop
1 428.749 428.870
2 433.881 430.811 <- less???
3 431.174 430.821 <- about the same
4 430.790

same test on eng-ckorda (10 passes):

y-loop x-loop
2049.676075 2039.400477
2048.712436 2038.438469
2050.792970 2037.090637
2050.447226 2035.422571
2048.608691 2037.680482
2048.793714 2037.724510
2046.311500 2036.718894
2046.910888 2036.637628
2048.768443 2036.429394
2047.345827 2028.997061

The x-loop test is doing more work but it's 0.5% faster!? Why? Must be a cache effect?

Retested on eng-ckorda, not alternating but doing y-loop tests first, then x-loop tests.

y-loop:
2237.09407
2062.133135
2136.322901
2257.790813
2327.423103
2238.671214

x-loop:
2209.896596
2193.642617
2163.614744
2373.648677
2223.055257
2042.156961

Looks pretty random... x-loop still faster on average though.

Thursday, October 1, 2009

Distributed movie rendering strategy

During distributed movie rendering, each server renders an entire frame at a time. This has pros and cons:

Pros:
Automatic load balancing. Since each server works at its own pace, servers can have different amounts of CPU power and remain fully utilized. Less powerful servers simply process less frames.

Optimal network usage. Sending entire frames minimizes transaction overhead, and allows the maximum potential for network streaming.

Cons:
Client receives rendered frames in arbitrary order. The client must reorder the frames before they can be written to a movie stream.

The proposed solutions to the arbitrary order problem are:

1) Write all the received frames to disk as uncompressed bitmaps, and defer creating the movie until all frames have been rendered.

Pros:
Simple to implement.
Doesn't require additional memory.
Allows recovery of a partially completed job.

Cons:
Requires huge amounts of disk space; must have sufficient disk space to store the entire movie as uncompressed bitmaps, even if the resulting movie will be compressed.

2) Store uncompressed frames--in memory or on disk--only as needed to resolve holes in the frame sequence.

Pros: Uses much less disk space; can create a compressed movie directly, without storing the entire movie as uncompressed bitmaps first.

Cons:
Complicated to implement.
Server failures must be handled carefully to prevent sequence holes from persisting.
If unresolved frames are stored in memory, could exceed available memory, especially if number of servers is large.
No way to recover a partially completed job.

Ideally both methods would be supported, allowing the user to choose the trade-off.

Thursday, July 23, 2009

mandelbar

instead of:
zy = 2 * zx * zy + b;
use:
zy = b - 2 * zx * zy;

Saturday, March 14, 2009

demo mode: vj settings

a: "vj set.frp", color cycling = .02667, slide show interval = 35.0
b: "vj set sno.frp", color cycling = .02447, slide show interval = 32.0
main:
autofade time = 10.0
motion:
defaults, except B phase = 0.5
misc:
palette tween time = 4.5 <- ??? too fast ??? 10.0 is better

Friday, February 27, 2009

optimal performance in exclusive mode

1. Image size should match screen
2. Turn "Fit to window" OFF
3. Hide the Levels bar (calculating the histogram takes ~12 ms for 1024 x 768 @ 2x AA)

Thumbnail creation takes ~15 ms for 1024 x 758, due to the horrendous performance of stretch blit in halftone mode, but there's nothing to be done about that for the moment.

Friday, February 20, 2009

invalid argument

NET version: "an invalid argument was encountered" dialog, repeats many times, occurs in dual monitor exclusive mode, after double-clicking a new snapshot in "cats eyes directdraw test.frp", i.e. a snapshot that has an image but no escape times. Fairly repeatable, try aborting a render by double-clicking a couple of snaps with escape times first, and then double-click one without escape times. Also occurs when transitioning into Exclusive mode. This is a bummer because Exclusive is nearly impossible to debug with the debugger. Disabling mirror, origin motion and color cycling has no effect! Does not prevent render from completing, but makes it take much longer than usual. The resulting image appears to be OK. By the time the render completes, approximately 50 dialogs (49?) have piled up. Switching between non-escape snaps works OK, switching between escape snaps works OK, the problem only occurs when switching from an escape snap to a non-escape snap. During the dialog display loop, the timer loop is blocked, so the rendering speeds up. Bizarre, it's only happening when the non-escape snap and escape snap are NOT related, i.e. going from a parent escape snap to its child non-escape snap doesn't show the problem.

MYSTERY SOLVED. Problem is due to *lowering* quality during a render. This causes the RGB palette to become smaller, but the escape frame still contains escape times from the previous RGB palette, some of which will inevitably be illegal indices for the new RGB palette, i.e. you will be reading beyond the end of the new RGB palette, causing some type of access violation. It only happens in Exclusive because normally you don't remap the color until the render is completed! The only imaginable solution is, when lowering quality, defer generating the RGB palette until after the render completes. When *increasing* quality, the current scheme is required, i.e. the RGB palette must be generated *before* the render to avoid an access violation. Very tricky.

Sunday, January 11, 2009

poster rendering

deep zoom 316 final frame at 10.5" x 8" 300dpi 2x took 478 minutes (8 hours) with 24 z machines