On Thursday 10 December 2009 16:26:33 Younes Manton wrote:
> On Thu, Dec 10, 2009 at 3:34 PM, Zack Rusin <za...@vmware.com> wrote:
> > On Thursday 10 December 2009 15:14:46 Younes Manton wrote:
> >> 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.
> >
> > In general it's safe to assume that pipe_context as the main Gallium3d
> > interface will largely model the modern pipeline. Meaning that the
> > Gallium3d pipeline will look a lot like D3D 11 pipeline because
> > realistically that's what's going to get the most attention from hardware
> > vendors. So effectively 1) input assembler
> > 2) vertex shader
> > 3) hull shader
> > 4) tessellator
> > 5) domain shader
> > 6) geometry shader
> > 7) rasterizer
> > 8) pixel shader
> > 9) compute shader
> > 10) output merger
> > When it comes to compute OpenCL is more robust so the compute resources
> > will be designed to make sure CL 1.1 is easily implementable and
> > certainly make it possible to use compute without graphics but the
> > pipeline itself will have to stay as outlined above otherwise we'd just
> > be asking for trouble. Does that make sense?
>
> Makes perfect sense, I just had a completely different looking, yet
> practically identical picture that put orthogonal functionality (2D,
> 3D, compute, video) in seperate 'contexts' as far as gallium was
> concerned, even if everything ended up in the same command buffer on
> the backend.
>
> pipe_foo_context { foo(); bar(); }
> pipe_shaz_context { shaz(); blam(); }
> ...
>
> vs
>
> pipe_context { foo(); bar(); shaz(); blam(); }
>
> If we want to grow pipe_context beyond just 3D then thats fine too,
pipe_context isn't so much about 3d as it is about abstracting modern
programmable graphics hardware. compute shaders are becoming part of the
pipeline so it's hard to exclude them. different contexts certainly make a lot
of sense but for parts that are adjoining to the pipeline, rather than within
it.
extracting compute code into another context would make a few things a lot
more complicated than they should be e.g. for d3d given the same context is
used for both and compute shaders are executed after and can communicate with
fragment shaders so we would have to create another object that would unify
the commands and resources of our pipe_ contexts in some way and then give
guarantees for execution order, for cl we'd need to port mesa to the new
interface to allow sharing of GL resources as defined in the CL spec. all
things that we get for free with one context.
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
