On 10/31/07, Zou, Nanhai <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Brian Paul [mailto:[EMAIL PROTECTED] > > Sent: 2007年10月31日 23:55 > > To: Zou, Nanhai > > Cc: Nan hai Zou; MESA-Devel > > Subject: Re: i965 glsl support > > > > Zou Nan hai wrote: > > > On Mon, 2007-10-29 at 23:58, Brian Paul wrote: > > >> Nan hai Zou wrote: > > >> > > >> [... git check-in info ...] > > >> > > >> Nan, > > >> > > >> Since you've merged the i965 GLSL support into Mesa/master, can you > > >> summarize what state it's in? Is it fully functional, or are there some > > >> unfinished bits? > > >> > > >> In any case, it's great to have this! > > >> > > >> I've found one problem, however. In shader/program.c in > > >> _mesa_new_shader() you added a call to ctx->Driver.NewProgram(): > > >> > > >> struct gl_program * > > >> _mesa_new_program(GLcontext *ctx, GLenum target, GLuint id) > > >> { > > >> if (ctx->Driver.NewProgram) > > >> return ctx->Driver.NewProgram(ctx, target, id); > > >> [...] > > >> > > >> > > >> This causes infinite recursive calls with software drivers since > > >> ctx->Driver.NewProgram is initialized to point to _mesa_new_program(). > > >> > > >> I'm going to disable this code. Let me know what problem you were > > >> trying to fix with this change. > > >> > > >> -Brian > > > > > > Hi Brain, > > > The state of glsl on 965 is that it is functional. > > > I have run the glean glsl test. 168 test passed except 1 case that do > > > texture sampling in vertex shader failed. > > > > > > The programs in prog/glsl/ works except the noise program. > > > > > > I am adding the Driver.NewProgram call is because 965 driver attach > > > some field after the brw_vertex/fragment_program field, > > > > Not sure I understand what you're saying. Can you explain? > > > > > > In i865/brw_program.c -> > i965 driver->NewProgram which is > brwNewProgram > allocate the data with CALLOC_STRUCT(brw_vertex_program), > struct brw_vertex_program is defined as > { > struct gl_vertex_program program; > GLuint id; > GLuint param_state; > }; > > the id and param state will be referenced during driver select or upload > program... > however _mesa_new_program only CALLOC_STRUCT(gl_vertex_program).
Right. _mesa_new_program() should only be used if you're deriving sub-classes of gl_vertex/fragment_program. > > > but mesa core > > > only allocate sizeof(brw_vertex/fragment_program), so I have to call > > > driver specific allocate function > > > > How is _mesa_new_program() getting called? It shouldn't be used at all > > with the i965 driver. > > > > In brwNewProgram, It will be called if the target is neither > GL_VERTEX_PROGRAM_ARB nor GL_FRAGMENT_PROGRAM_ARB. So normally > _mesa_new_program() will not be called from i965 driver. > > This is usually called from slang_compile.c and slang_emit.c. > > So maybe we should call Driver->NewProgram instead of directly calling > _mesa_new_program in slang_compile.c and slang_emit.c? I fixed that quite a while ago. There's only one place where _mesa_new_program() is called in the glsl code and that's just for temporary storage (for subroutines). So, I don't think there's a problem here. I'll remove the #if 0 / #endif code from program.c. -Brian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
