It is good to see that AMD is being true to their word. :D
Type: Posts; User: Seth Hoffert
It is good to see that AMD is being true to their word. :D
Nope, the D3D11 tessellator is more general than that one - check the gamefest slides if you're interested. :)
Maybe we'll get to use it first in OpenGL with an extension. :D
OpenCL will be the compute shader equivalent (well, minus the scattered writes in the pixel shader I suppose - extension?)
I'm willing to bet that NVIDIA will be good about putting out an...
The function either needs to be known for the exact partial derivatives, or you could estimate them, which is essentially what you're doing right now with the neighbor technique.
One thing to try...
When I mentioned compute shaders, I was actually referring to D3D11 itself. I'm emphasizing that it really is OK to like both APIs.
I am looking forward to OpenCL as well, and I'm glad to see...
I have found instancing to be quite elegant in GL; and I have also not had issues with D3D10 draw call overhead in my programs.
I have found a couple of uses for the geometry shader - like...
The matrix needs to be evaluated at each vertex, so it will necessarily not be the same. You will basically end up with a huge buffer of per-vertex matrices, which is not very efficient.
I think...
Since you're essentially transforming from 2D to 3D, you end up with a 3x2 Jacobian matrix. The first column contains the partial derivatives with respect to u of your x(u,v), y(u,v), and z(u,v)...
From the EXT_gpu_shader4 specification:
Using this, you can declare a custom integer output varying and bind it to color output 0.
Yep, I'm afraid there's not much you can do about it. This is what I meant when I said the quality wouldn't be as good. ;)
Really though, what you could do is just compute the forward derivatives...
Yes, dFdx() and dFdy().
Something like this should do the trick:
vec3 n = -normalize(cross(dFdx(eye), dFdy(eye)));
This way, all you need to compute in the vertex shader is the eye vector. :)
In a parametric function plotter I wrote, I use the forward and backward derivative formulas to compute the derivatives, which basically amounts to executing the user-defined function four times with...
I think you're right in that Direct3D will stick around to provide an abstraction. Just looking at D3D11, I believe a whole new class of algorithms will be possible. The pixel shader being able to...
With ARB_instanced_arrays, you can store the per-instance data in attributes.
This is good to see - and sooner than expected! :D
It would be really, really cool if OpenCL worked in Windows. Then one could use OpenGL along with OpenCL on all major platforms. :D
That's true, the jump from fixed function to programmable shaders is tough to beat. I was thinking more in terms of the API clean-up (the dropping of fixed functionality) and the addition of...
Yeah, I found that part to be a bit absurd. D3D10 is definitely much larger than an "incremental change." Oh well. :)
The ARB_texture_non_power_of_two extension relaxes the power-of-two restriction.
True, Korval, I hadn't even thought about pointers yet.
Looking over the OpenCL spec again, it does look pretty promising. The fact that it can run across GPUs and CPUs is nice.
Call me crazy,...
I am secretly hoping that Larrabee comes along and owns everything out there currently, but I have a number of concerns.
It is my understanding that Larrabee still has special texture-related...
It does seem that MS is pushing double support, which is a good sign. One of the slides mentions the importance of this for scientific applications.
I definitely like that the compute shader uses...
Why not just use a triangle strip with 4 vertices instead of a quad?
EDIT: I suppose you'd need glMultiDrawArrays or glMultiDrawElements, nevermind...
I was also going to mention the geometry...
I didn't realize the presentations were up already - nice!
It looks like one can use the compute shader separately from the graphics pipeline (Dispatch()), but the pipeline has been updated to...