On Tue, Oct 20, 2015 at 1:41 AM, Rob Clark <robdcl...@gmail.com> wrote: > On Mon, Oct 19, 2015 at 7:07 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Mon, Oct 19, 2015 at 11:52 PM, Rob Clark <robdcl...@gmail.com> wrote: >>> On Sat, Oct 10, 2015 at 9:09 PM, Marek Olšák <mar...@gmail.com> wrote: >>>> From: Marek Olšák <marek.ol...@amd.com> >>>> >>>> I'll let drivers figure out how to do it. >>>> --- >>>> src/gallium/docs/source/screen.rst | 2 ++ >>>> src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >>>> src/gallium/drivers/i915/i915_screen.c | 1 + >>>> src/gallium/drivers/ilo/ilo_screen.c | 1 + >>>> src/gallium/drivers/llvmpipe/lp_screen.c | 1 + >>>> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >>>> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >>>> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >>>> src/gallium/drivers/r300/r300_screen.c | 1 + >>>> src/gallium/drivers/r600/r600_pipe.c | 1 + >>>> src/gallium/drivers/radeonsi/si_pipe.c | 1 + >>>> src/gallium/drivers/softpipe/sp_screen.c | 1 + >>>> src/gallium/drivers/svga/svga_screen.c | 1 + >>>> src/gallium/drivers/vc4/vc4_screen.c | 1 + >>>> src/gallium/include/pipe/p_defines.h | 1 + >>>> 15 files changed, 16 insertions(+) >>>> >>>> diff --git a/src/gallium/docs/source/screen.rst >>>> b/src/gallium/docs/source/screen.rst >>>> index e08844b..72f7596 100644 >>>> --- a/src/gallium/docs/source/screen.rst >>>> +++ b/src/gallium/docs/source/screen.rst >>>> @@ -276,6 +276,8 @@ The integer capabilities: >>>> GL4 hardware will likely need to emulate it with a shader variant, or by >>>> selecting the interpolation weights with a conditional assignment >>>> in the shader. >>>> +* ``PIPE_CAP_SHAREABLE_SHADERS``: Whether shader CSOs can be used by any >>>> + pipe_context. >>> >>> An extra sentence along the lines that drivers supporting this cap can >>> save pipe->screen ptr but not pipe ptr in the CSO might not hurt.. >>> >>> other than that nitpick, lgtm.. >> >> I don't understand why drivers would want to put either of them into >> the CSO. All calls manipulating the CSO take pipe_context, so you >> always have some pipe_context and pipe_screen if you need them. The >> correct answer - don't put any of them into the CSO - applied before >> and still applies. > > My point was, pipe_screen never changes for the CSO but pipe_context > can.. I need the pipe_screen to stay the same for allocating memory > to hold the shader, figure out which gpu generation for some things > that differ between a3xx/a4xx in the backend, etc. > > Sure technically you could pass the screen down the call stack instead > of storing it in CSO.. for me that would be a lot of adding extra fxn > param's in a bunch of places, so I won't bother (but I would replace > the current pipe_context ptr w/ pipe_screen, and update the emit code > to pass down the ctx)
That's a fair point. Well, you can use whatever structure you want as long as it's thread-safe. Even pipe_screen might not be thread-safe in some drivers. :) Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
