On Thursday 10 December 2009 14:35:47 Younes Manton wrote: > Well how do we keep the compute state seperate from the 3D state, and > how do you mix the two?
It's really the same state. You bind a compute shader and execute it. It doesn't affect the rest of your state. Compute binds the buffers pretty much exactly like you'd bind them for any other api, and the "pretty much" comes only from the fact that you can bind structured buffers with compute for scatter reads/writes which purely graphics api don't have a lot of need for. > Do you have two state trackers using the same > pipe_context and re-emitting their entire states to the HW as > necessary? Why would that be necessary? Compute doesn't destroy the state that's been set for graphics. > Do you use two pipe_contexts? That depends on how the context was created, i.e. it's up to API and the users to decide how they want to use it. With d3d a lot of usage might be shared, with opencl a lot of usage will use a separate context. > What about cards that know about compute and keep a seperate state? Well, a) compute doesn't care about the 3d state so that should be fine, b) if they shared some intrinsics parts of the state between the scenes they became deprecated the second D3D11 introduced compute shaders. > When you set a shader/read buffer/write buffer/const buffer with the > pipe_context it's not clear to me what we should do on the driver's side. You should set a shader/read buffer/write buffer/const buffer like pipe_context asks you to =) > The card basically has seperate state for DMA, 2D, 3D, video, compute > on nv50+, and a bunch of others. When we create a pipe_context we bind > the DMA, 2D, and 3D and some of the others and issue commands. For > nv50 we have a compute state, but we need to know what to do with > commands coming through pipe_context, are they for 3D or compute? The compute state is for compute, the 3d specific state is for 3d =) When we'll do context->bind_compute_shader(...) surely you'll know that you're supposed to set the compute shader. And for buffers NVIDIA and really anyone can't require that distinction because they wouldn't be able to implement d3d compute shaders. We'll likely add a buffer flag anyway, just to make it explicit that a certain buffer will be utilizing unordered access, just like most likely will slip in a dispatch(int work_groups_x, int work_groups_y, int work_groups_z) call. it really all boils down to a very simple math: the first api all ihv support is directx => directx does it => we better do it. z ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
