On 01/21/2013 08:52 PM, Paul Berry wrote:
On 21 January 2013 14:48, Kenneth Graunke <kenn...@whitecape.org
<mailto:kenn...@whitecape.org>> wrote:

    On 01/21/2013 01:38 PM, Eric Anholt wrote:

        Kenneth Graunke <kenn...@whitecape.org
        <mailto:kenn...@whitecape.org>> writes:

            ---
               src/mesa/drivers/dri/i965/brw___state.h             | 3 ++-
               src/mesa/drivers/dri/i965/brw___wm.c                | 2 +-
               src/mesa/drivers/dri/i965/brw___wm_surface_state.c  | 8
            ++++++--
               src/mesa/drivers/dri/i965/__gen7_wm_surface_state.c | 4 ++--
               4 files changed, 11 insertions(+), 6 deletions(-)

            I believe the
            BRW_NEW_VERTEX_PROGRAM/BRW___NEW_FRAGMENT_PROGRAM dirty bits
            on the brw_texture_surfaces atom should cover my new usage
            of shProg.
            Eric, can you confirm?  I always get confused by
            _NEW_PROGRAM vs.
            CACHE_NEW_WM/VS_PROG vs. BRW_NEW_VERTEX/FRAGMENT___PROGRAM.
              Thanks!


        CACHE_NEW_*_PROG covers prog_data, BRW_NEW_*_PROGRAM covers the
        brw_*_program and gl_shader_program structs, so that sounds
        good.  But I
        see an issue anyway...

            diff --git
            a/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c
            b/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c
            index 5e99592..b609b09 100644
            --- a/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c
            +++ b/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c
            @@ -685,8 +685,10 @@
            brw_get_surface_num___multisamples(unsigned num_samples)
                * swizzling.
                */
               int
            -brw_get_texture_swizzle(const struct gl_texture_object *t)
            +brw_get_texture_swizzle(__struct gl_context *ctx,
            +                        const struct gl_texture_object *t)
               {
            +   const struct gl_shader_program *shProg =
            ctx->Shader.___CurrentFragmentProgram;


        You're looking at the FS even if we're trying to set up textures
        for the
        VS.  I think the caller should pass in the particular program,
        and then
        it'll be more obvious to the caller which state flag is right.


    Eric mentioned this on IRC:

    <anholt> Kayden: oh, I suppose my comment about looking at the wrong
    program in your depth change doesn't really matter since Version
    will be the same in both.

    which is true - otherwise the VS/FS link would have failed.


Is this still going to be true when we implement
ARB_separate_shader_objects?

No, but a lot of this code is going to have to get reworked when we do that.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to