On Thu, Dec 10, 2009 at 3:03 PM, Zack Rusin <za...@vmware.com> wrote: > 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.
OK, so we seem to be on the same page here, pipe_context will get some more functions. That's what I was originally asking about, will pipe_context grow or will there be a new kind of context? From my POV we would end up in roughly the same place either way. ------------------------------------------------------------------------------ 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
