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

Reply via email to