|
Feline
|
 |
« on: June 09, 2013, 12:20:21 AM » |
|
So I got myself a new laptop with Win7-64bit and Quadro K2000M graphics. 384 shaders, baybeee.
I went to github and downloaded 0.9.12b (I already had that, but just to make sure I get the newest of everything in the library) and when I fire it up it's pleasantly smooth and fast and ... has a diagonal drawn across it. Huh. I'll attach an example.
Here's what I can figure out so far:
- The diagonal is independent of camera settings
- It appears with DE-Raytracer and with DE-Raytracer-v0.9.10 but not(!) with Fast-Raytracer
- It disappears when I change BufferShader in 3D.frag to BufferShaderIFS
I'm guessing there's something going on somewhere that results in a rounding error of some sort when coord.x equals coord.y (is there an atan(coord) somwhere? SOmething like that?) But for the life of me I can't figure out where that is. I have no idea why my (new, shiny, Kepler-based) graphics card should be susceptible to it while my dinky old GF7000M wasn't.
Anybody have any ideas?
|
|
|
|
Logged
|
|
|
|
|
|
|
Syntopia
|
|
« Reply #2 on: June 09, 2013, 05:23:26 PM » |
|
Here's what I can figure out so far:
- The diagonal is independent of camera settings
- It appears with DE-Raytracer and with DE-Raytracer-v0.9.10 but not(!) with Fast-Raytracer
- It disappears when I change BufferShader in 3D.frag to BufferShaderIFS
Anybody have any ideas?
Interesting. Perhaps it has something to do with the offscreen buffer. Fast-Raytracer and BufferShaderIFS do not use the floating-point offscreen buffers ("#buffer RGBA32F"). What happens if you render a high-resolution image? I'm also a little bit curious about the screenshot. It appears that your buttons and graphics style is the old WinXP style. Are you using a special kind of skin? Also, how many frames per second do you get on the Mandelbulb when in continous mode? (hopefully a lot more than number on the screenshot indicates). Microsoft REMOVES MOST of the OpenGL code from the driver you get from "Auto-updates"
It is an on going attempt to try to kill off OpenGL
I really don't think that is the case. Where have you heard about this? |
|
|
|
|
Logged
|
|
|
|
|
Feline
|
|
« Reply #3 on: June 09, 2013, 10:29:42 PM » |
|
Lessee: the buttons and such are just "Windows Classic" theme in "personalization". I don't go for the transparent and rounded-corner things that have been floating around for a while (XP is by default rounded-corner as well, but most people I know just revert back to Win98 style).
On the default Mandelbulb in continuous mode I get from 30 to 33 fps, depending on the direction I turn it to (and yet different numbers upon zooming, of course).
Hi-res renders have the diagonal in each sub-panel, resulting in an apparent multiple diagonals across the image once it's re-assembled.
The diagonal is always one pixel wide, independent of window size. I note that it's always from lower left to upper right corner, independent of aspect ratio (so the problem is not in object space).
I'm using the driver than came with the laptop, but downloading the latest from Nvidia is probably not a bad idea, if only for good housekeeping. I'll report back if that changes something.
(FP offscreen buffers, eh? Back in the eighties I once ran into a problem where some math failed depending on whether I approached zero from above or below because of an odd FP implementation that distinguished internally between "plus zero" and "minus zero" and failed to find them "equal". This long-buried memory was just triggered, and may have nothing to do with the case at hand...)
|
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #4 on: June 09, 2013, 10:56:52 PM » |
|
Lessee: the buttons and such are just "Windows Classic" theme in "personalization". I don't go for the transparent and rounded-corner things that have been floating around for a while (XP is by default rounded-corner as well, but most people I know just revert back to Win98 style).
Yep, they have been around for a while :-) (FP offscreen buffers, eh? Back in the eighties I once ran into a problem where some math failed depending on whether I approached zero from above or below because of an odd FP implementation that distinguished internally between "plus zero" and "minus zero" and failed to find them "equal". This long-buried memory was just triggered, and may have nothing to do with the case at hand...)
Yes, signed zeroes are required by the IEEE754 standard. However +0==-0 should be true :-) We can test the buffer thing: #buffer RGBA32F
//#buffer RGBA16F
//#buffer RGBA8
//#buffer NONE
#vertex
varying vec2 viewCoord;
uniform vec2 Center; slider[(-10,-10),(0,0),(10,10)] NotLockable
uniform float Zoom; slider[0,1,100] NotLockable
void main(void)
{
gl_Position = gl_Vertex;
viewCoord = (gl_ProjectionMatrix*gl_Vertex).xy;
}
#endvertex
varying vec2 viewCoord;
void main() {
vec2 c = viewCoord*1.5;
gl_FragColor = vec4(cos(c.x),sin(c.y),sin(c.x*c.y),1.0);
}
Try using different buffer types and see if it matters. The ones with F are floating point buffers. |
|
|
|
|
Logged
|
|
|
|
|
Feline
|
|
« Reply #5 on: June 10, 2013, 05:42:49 AM » |
|
Ever more interesting stuff.
None of the four types show the diagonal line. Including the 32F
So I tried a few things from Example|2D and it's inconclusive. BurningShip and Ducks have the line, Droste and Game of Life do not. Graphplotter has it, Mandelbrot-DE doesn't. But Mandebrot has it. Huh.
16F led to a complaint:
Unknown buffertype requested: RGBA16F. Type must be: NONE, RGBA8, RGBA16, RGBA32F
Changing it to RGBA16 works. No line there either.
I hadn't looked at it before at all, so I re-started the application and upon startup it tells me "This graphics card supports: ". With nothing following it. Hum.
I went to Nvidia's webpage and downloaded the newest driver package (v320; the one that came installed on this laptop was v296). Installed it, restarted, no change: the line is still there and it still tells me this card supports " "
In MandelbrotOrbitTrap I realized that it has a line in the default version that uses Progressive2D, but when I change that to the simple 2D and rebuild then the line vanishes. PenroseTiles does not have a line and it uses "2D" - when I change it to "Progressive2D" the line appears. Thorn uses Progressive2DJulia and has the line. The line vanishes when I change this to "2DJulia" (and use Antialiasing instead).
Just as with Fast-Raytracer, this suggests the bug is somewhere in the progressive code, I guess.
Keep the ideas coming, everybody :-)
|
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #6 on: June 10, 2013, 09:32:36 PM » |
|
Hmmm... Mandelbrot-DE also use progressive2D rendering, doesn't it? Try the example again with progressive rendering: #buffer RGBA32F
#buffershader "BufferShader.frag"
#vertex
varying vec2 viewCoord;
uniform vec2 Center; slider[(-10,-10),(0,0),(10,10)] NotLockable
uniform float Zoom; slider[0,1,100] NotLockable
void main(void)
{
gl_Position = gl_Vertex;
viewCoord = (gl_ProjectionMatrix*gl_Vertex).xy;
}
#endvertex
uniform float Gamma; slider[0.0,2.2,5.0]
uniform int ToneMapping; slider[1,1,4]
uniform float Exposure; slider[0.0,1.0,30.0]
uniform float Brightness; slider[0.0,1.0,5.0];
uniform float Contrast; slider[0.0,1.0,5.0];
uniform float Saturation; slider[0.0,1.0,5.0];
uniform float AARange; slider[0.0,2.,15.3]
uniform float AAExp; slider[0.0,1,15.3]
uniform bool GaussianAA; checkbox[true]
uniform int backbufferCounter;
uniform sampler2D backbuffer;
varying vec2 viewCoord;
void main() {
vec2 pos = (viewCoord+vec2(1.0))/2.0;
vec2 c = viewCoord*0.5*backbufferCounter;
vec3 color= vec3(cos(c.x),sin(c.y),sin(c.x*c.y));
vec4 prev = texture2D(backbuffer,(viewCoord+vec2(1.0))/2.0);
gl_FragColor =prev+vec4(color,1.0);
}
|
|
|
|
|
Logged
|
|
|
|
|
Feline
|
|
« Reply #7 on: June 10, 2013, 10:34:39 PM » |
|
Actually, Mandelbrot-DE uses 2D.frag, not Progressive2D.frag.
The new example looks weird: three quadrants are black, the upper right is reddish and it does have the white line. When I hit "continuous", the outer half of that upper right quadrant turns black as well, but the white line is still there.
I think the problem is the trig functions in "color" that go negative. I get all four quadrants appropriately colored (and a nice white diagonal) if I add one to gl_FragColor:
gl_FragColor =prev+vec4(color,1.0)+1;
but it is unclear to me why this didn't trip things up with the previous example...
(Edit) in this second example, when I change RBGA32F to RGBA16, nothing is black - it's all nicely colored. However, it all changes scale when I hit "continuous" (or when I drag another window in front of it).
And it does still have the same white diagonal line.
|
|
|
|
« Last Edit: June 12, 2013, 09:07:26 AM by Feline »
|
Logged
|
|
|
|
|
Feline
|
 |
« Reply #8 on: June 12, 2013, 10:42:09 PM » |
|
Now here's another surprise on the same front.
For experiment's sake, I tried the second example (from June 10) on my "real computer": a seven-year-old dual-xeon that isn't particularly good at anything except that it has a Tesla-C2070 in it.
Mainly I wanted to verify that, indeed, 3/4 of the display starts out black and, indeed, the scaling of the image changes when I switch to "continuous". I.e. that there's a problem with the .frag file, not with the laptop. And indeed, all this came up exactly as described previously, except that it didn't have that odd diagonal line.
Just to verify the rest, I changed #buffer RGBA32F to #buffer RGBA16 and indeed the whole screen is now reddish-yellow and indeed it still changes pattern-scale when I hit "continuous" BUT(!) I do now also see the diagonal line on this completely different graphics card (two year old, Fermi architecture, 448 cores, vs my laptop's brand-new, Kepler architecture, 384 cores).
This means whatever bug there is in the accumulating shader code was there all along - just obscured by whatever Fermi cores do differently in the floating point arena from Kepler cores...
Could someone out there try this and confirm or deny that indeed the code snippet syntopia posted on Jun-10 in this thread, when put into a .frag file and opened in fragmentarium, creates a thing diagonal line on the screen in the upper right quadrant IF the first line is changed as noted above?
|
|
|
|
« Last Edit: June 12, 2013, 10:44:56 PM by Feline »
|
Logged
|
|
|
|
|
cKleinhuis
|
|
« Reply #9 on: June 12, 2013, 10:54:33 PM » |
|
this is how it looks with RGBA16 and continous:
i am using a radeon hd 6800 graka
|
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
elphinstone
|
|
« Reply #10 on: June 13, 2013, 10:03:18 AM » |
|
GTX 680, driver 314.22 - I confirm I have a diagonal from the bottom left to the top right corner.
|
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #11 on: June 13, 2013, 05:57:45 PM » |
|
I tried Fragmentarium on a Geforce 570GTX and found that I also get the diagonals when using RGBA16. I manage to reduce the code to BufferShaderX.frag#vertex
varying vec2 coord;
void main(void)
{
gl_Position = gl_Vertex;
coord = gl_Vertex.xy;
}
#endvertex
varying vec2 coord;
uniform sampler2D frontbuffer;
void main() {
vec2 pos = (coord.xy+vec2(1.0))/2.0;
vec4 tex = texture2D(frontbuffer, pos);
gl_FragColor = vec4(tex.a);
}
#buffer RGBA16
#buffershader "BufferShaderX.frag"
#vertex
void main(void)
{
gl_Position = gl_Vertex;
}
#endvertex
void main() {
gl_FragColor =vec4(0.5);
}
So the error is not in the shader code. The error only happens when I read from a integer based texture (RGB8, RGB16) and only when sampling the alpha channel. My guess is that the full-viewport quad I'm drawing is converted into triangles, and that the Geforce Fermi cards does some kind of manipulation near the edges (interpolation, alpha-blending, MSAA supersampling?). The Keppler cards probably do the same in floating-point mode to. |
|
|
|
|
Logged
|
|
|
|
|
eiffie
Guest
|
|
« Reply #12 on: June 13, 2013, 08:05:15 PM » |
|
If you calculate the coords in the fragment shader does it go away?
|
|
|
|
|
Logged
|
|
|
|
vinz
Iterator
Posts: 154
|
|
« Reply #13 on: June 13, 2013, 08:40:24 PM » |
|
Dunno if it can help anyway : here GTX 580 drivers 310.90 on winx64
and no diagonal issue.
|
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #14 on: June 13, 2013, 09:45:49 PM » |
|
I convinced myself this is a dual triangle edge problem. I have created a new build where I render to buffer using a single (larger-than-viewport) triangle instead of a quad. Please try it, to see if it solves the problem: http://hvidtfeldts.net/Fragmentarium-Triangle.zip(Replace the fragemtarium.exe with the one in this zip). |
|
|
|
|
Logged
|
|
|
|
|
February 26, 2012, 11:53:43 PM
Dilber MC Theme by HarzeM