A very strange error: if I add some specific code to my project, any textures I use contain nothing but 0. Even when I'm not running any of the code that was added.
The specific code here is the kernels of an nVidia CUDA sample [1], the Bicubic Texture Filtering sample, in specific the CatMulRom kernel. I've traced it down to one of the subfunctions. If I reset a variable there, everything returns to normal. It's really, really strange and I have no idea anymore what it could be. Adding and using the bicubic kernel causes no problems.
Here's the change that "fixes" the problem:
__host__ __device__
float catrom_w1(float a)
{
a = 1; // Fix
return 1.0f + a*a*(-2.5f + 1.5f*a);
}
If I reset the variable, it works if I'm not using CatMulRom. If I do try to use it the textures are zero again. The textures in question are defined as follows:
texture<uchar1, 2, cudaReadModeNormalizedFloat> tex;
I've edited away the template, hoping it would solve the problem, but it persists.
[1] http://developer.download.nvidia.com/compute/cuda/sdk/website/samples.html
You've busted your stack.
Related
For our multiplatform engine that supports both OpenGL and DirectX9 I am adding support for decals. In OpenGL I can set glPolygonOffset(-1.0f, -1.0f) to fix z-fighting between the wall and the decals. I want the DirectX version to behave exactly the same, so I call this:
float offsetFloat = -1.0f;
DWORD offsetDWord = *((DWORD*)&offsetFloat);
device->SetRenderState(D3DRS_DEPTHBIAS, offsetDWord);
device->SetRenderState(D3DRS_SLOPESCALEDEPTHBIAS, offsetDWord);
However, this gives me an extremely large depth bias. It seems I need to use extremely small values in DirectX9. However, I can't seem to find how small.
I noticed that in the OGRE engine's source they're dividing by 250000, but despite the comment I don't quite see where that number comes from. Also, they only divide the constant by that for some reason?
// D3D also expresses the constant bias as an absolute value, rather than
// relative to minimum depth unit, so scale to fit
constantBias = -constantBias / 250000.0f;
__SetRenderState(D3DRS_DEPTHBIAS, FLOAT2DWORD(constantBias));
slopeScaleBias = -slopeScaleBias;
__SetRenderState(D3DRS_SLOPESCALEDEPTHBIAS, FLOAT2DWORD(slopeScaleBias));
So my question: what do I need to pass to DirectX9 to get the exact same result as glPolygonOffset?
I haven't found an exact number anywhere, but by experimenting I have figured out that to get roughly the same effect in OpenGL and DirectX, I need to divide by 3500000, instead of the 250000 mentioned above.
If anyone knows the exact number or why it's this, I'd love to hear that, but for practical purposes I think this conclusion will do for me.
If you look at the equations for OpenGL polygon offset and the equivalent Direct3D 9 renderstates, you'll find that they're identical, other than OpenGL has a term for an implementation-dependent constant value. If we assume that value is 1, the equations do become identical.
The obvious problem here is: what happens when the value is not 1?
Unfortunately OpenGL doesn't seem to provide a way of querying it, so the only thing you can do is twiddle parameters until you find something that works, then twiddle them some more as edge cases arise, and never assume that what works for you will work for anyone else.
Direct3D's assumption that the value is always 1 may not necessarily hold good all the time either.
Bottom line is that polygon offset is not a 100% robust method for fixing z-fighting under any circumstances. Have you tried other methods, such as pushing your decals out an epsilon along the surface normal?
I just started with PETSC and I'm trying to plot a matrix using matView. My code is like:
MatCreateSeqAIJWithArrays(PETSC_COMM_WORLD, nodes, nodes, rows, cols, values, net); //I want to visualize "net"
//Visualization
if(display >= 1){
PetscPrintf(PETSC_COMM_WORLD, "CSR structure created.\n");
MatView(*net,PETSC_VIEWER_DRAW_WORLD);
}
When I use MatView this way:
MatView(*net,PETSC_VIEWER_STDOUT_WORLD);
I can see a list with the rows. But when I change it to
MatView(*net,PETSC_VIEWER_DRAW_WORLD);
nothing happens.
I can't see anything about net structure, not even the list.
I tried to run the examples but they don't work at all. Also, the PETSC documentation just makes things worse. Can someone help me? I don't want to see a list of rows, but the matrix (graphically).
More context from the comments:
X windows is functioning properly -- was able to confirm with gvim, xlogo, xeyes, etc.
Library has been rebuilt using --with-x option in configure. Still nothing appears.
Try using "-draw_pause -1" as an argument to your PETSc program, if you're not doing it yet.
-draw_pause - Sets time (in seconds) that the program pauses after PetscDrawPause() has been called (0 is default, -1 implies until user input).
What is the equivalent of the following for a C-mex s function? That is, how do I set discrete sample time of a block to the top level fixed step size in C?
My problem is, I could not find a way to "get" the top level fixed step size parameter in C-mex.
function setup(block)
block.SampleTimes = [str2double(get_param(bdroot, 'FixedStep')) 0];
Use ssGetFixedStepSize to get the base rate of the model. You may also want to ssSetErrorStatus if the that call returns 0, because that means your model is not configured with a FixedStep solver.
If, for some reason, you really want to go about fetching the information similar to what you have in the question, then you might be able to get access to it if you dig through the SimStruct pointer's fields. To do this, breakpoint in the mex file using a debugger and watch that variable.
Another option would be a few mexCallMATLAB calls to get the information you want.
Doing some simple plotting and I cannot seem to figure out why I can't plot my data. I troubleshooted it first by checking to see if I had any data in my arrays first. I did not!! I'm completely lost on how to fix this.
I also tried creating a script to see if maybe it solved the issue instead of using the command window. I still get the same error.
Code:
t=0:1e-6:((2e-3-1e-6)-1);
vm=sin(2*pi*1e3*t);
vc=sin(2*pi*20e3*t);
vdsb=vc.*vm;
plot(t,vdsb,'b')
You probably don't want that last -1 in your code setting up t. Try changing t to:
t=0:1e-6:((2e-3-1e-6));
Or, if you really want it negative, you need to change the step size to negative:
t=0:-1e-6:((2e-3-1e-6)-1);
Otherwise, t is defined from 0:psotiveStep:negativeNumber and so it is empty.
I have a WebGL fragment shader that I am using to do raytracing. I pass in sphere and triangle data using textures. So far I've got 2 spheres and 3 triangles working. When I add the call to check interesection with a 4th triangle, the shader does not link, and calling getProgramInfoLog() just returns null.
Could the fragment shader be getting too big? Or do I need to look for another cause? How do I determine where the problem might be?
Here is a code snippet, commenting out any one of the checkTriangleIntersection calls causes the shader to link successfully.
checkTriangleIntersection(0.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
checkTriangleIntersection(1.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
checkTriangleIntersection(2.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
//checkTriangleIntersection(3.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
Since all the calls are the same, except for the index, I thought that there would be nothing wrong with the code itself, but is there some kind of limit that I could be running up against?
I'm getting more then 30 FPS before I add the extra function call, and even when I do add the extra call, both the vertex and fragemnt shader compile OK.
I got rid of the issue by putting the calls to checkTriangleIntersection() into a for loop.