Demos render "fuzzy" on Linux/Xorg

[takikawa]

Some of the demos render with fuzzy dots for me. Here's an example picture:

The machine I used for this runs Linux/Xorg with a Radeon HD 6450 (using the free software "radeon" driver).

[ntoronto]

Does the following program also render with spots?

#lang racket
(require pict3d)
(with-color (rgba "white" 0.75)
  (sphere origin 1/2))

[ntoronto]

Also, do the spots jump around while the animation is running?

If they do, what happens if you change the beginning of the snowman function to this?

(define (snowman t)
  (set! t 0)

[takikawa]

Your test program didn't render with spots for me (in DrRacket's REPL).

They do jump around, but after making that change they do not move.

[ntoronto]

Thanks, that narrows it down tremendously. I think I can rule out uninitialized memory, and focus on the differences between the shaders for opaque and transparent ellipsoids (of which there are few).

[ntoronto]

OK, it's more subtle than I thought. Next time you get a chance, can you update to the latest, run "pict3d/tests/debug-passes.rkt" in DrRacket, and take a screenshot?

#lang racket
(require pict3d/tests/debug-passes)

The output should look like this:

(I've wanted this debug functionality for a while now, and this was a good excuse.)

[takikawa]

Sure, here you go:

[takikawa]

FWIW, I noticed earlier that I get this with the sphere example from the manual too:

But it seems only if I disable the axis arrows. Also just (sphere origin 1/2) does the same. The lighting button doesn't seem to matter.

[ntoronto]

The fact that part of the sphere on the right in the "debug-passes.rkt" test is clipped off is telling, as is the rendering pass it happens in. I've got a much better idea where to look now. Thanks.

(It's clipped instead of speckled probably because that test sets the near and far clipping plane distances to values much closer to 1. That's significant, but I don't know how yet.)

FWIW, and this is completely unrelated, and doesn't affect Pict3D unless you want to render onto transparent backgrounds: your graphics driver's GLX implementation (the layer between OpenGL and the windowing system) should be returning an RGBA context if possible, but it's returning an RGB context. That's probably an error in the driver. If you run glxinfo and paste in its output, I should be able to tell you for sure.

[ntoronto]

OK, here's what I think it is: the pass that produces opaque-rgba has to draw all the shapes in the scene that the pass that produces opaque-material and opaque-depth draws. Not only that, but it has to produce exactly the same floating-point values for the depth of every pixel in each shape.

For some reason, the depth values aren't exactly the same. I suspect there's a floating-point unit on your card whose square root function, which spheres use but polygons don't, is slightly different than the others. Either that, or the driver is optimizing the material pass fragment shader differently than the compositing pass fragment shader.

"Test these floats for equality" is iffy at best, so I've always disliked this part of multipass rendering. I'll see if I can do something more robust.

[ntoronto]

Turns out there are tons of little "invariance" conditions on such things as shader output. From what I can see, your card is acting within spec on the fragment shader depth output in particular. I'm going to try to arrange OpenGL's state and the fragment shader code to meet the invariance conditions.

[ntoronto]

Potential fix pushed. Next time you get a chance, can you try the snowman and debug passes?

[pafalium]

I tried the 88b7d79ac702b1a7cdefe90308983fa42ac1283b, Now, when I try to run the example with the hd7970m I get this shader compile error:

AppData\Roaming\Racket\6.1.1\pkgs\pict3d\pict3d\tests\debug-passes.rkt:29:25: make-gl-shader: Geometry shader failed to compile with the following errors:
WARNING: 0:11: warning(#288) Divide by zero error during constant folding
ERROR: 0:104: error(#236) varying expected: geom_trans_z
ERROR: 0:104: error(#236) varying expected: geom_trans
ERROR: 0:104: error(#236) varying expected: geom_untrans
ERROR: 0:105: error(#236) varying expected: frag_trans_z
ERROR: 0:105: error(#236) varying expected: frag_dir
ERROR: 0:105: error(#236) varying expected: frag_start
ERROR: error(#273) 6 compilation errors.  No code generated

When I try it on the "intel hd graphics 4000" everything goes fine.

[ntoronto]

I'll push a workaround for the buggy driver shortly.

I was afraid something like this might happen. Thanks for testing it so quickly.

[ntoronto]

@pafallum: Pushed. This may or may not fix it, depending on... reasons.

[pafalium]

Tested. It's working now.

[ntoronto]

Excellent, thanks.

[takikawa]

I still see spots on commit 2be02e57b4f087f905a4e28687f15a52dc51ba88. Also if I resize the window it does other strange things. It turns purple, green, and gets clipped as well.

Here is the output of the debug pass:

And here is a dump of my glxinfo output: https://gist.github.com/takikawa/6331d96bd4120457e1aa

[ntoronto]

Whoa!

Fortunately-ish, the latest changes have made it easier for me to replicate the "resizing the window makes weird things happen" bug. I'll tackle that next, and then try to squash the speckles again.

BTW, the driver is wrongly returning a framebuffer without an alpha channel. In response to what Racket asks for, it should return FB config 0x07c as the top non-multisampling match. I have no idea how you'd formulate a bug report for it, though.

[ntoronto]

OK, the last push should fix everything.

Right.

[takikawa]

On c5775eb30405be6cf04a7b86e3a640093e8ef3a9 I no longer see spots on the snowman. Resizing the window also seems fine. The debug passes look fine too modulo the alpha channel issue. Also tried the nuclear sausage plant demo and it looks fine too. Yay.

[ntoronto]

Excellent! Thanks for helping out.