It was pretty simple IIRC. You just need to call st_get_fp(vp)_variant to create a pipe shader. I think st_program_string_notify is the right place.
Marek On Mon, Jan 20, 2014 at 7:23 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Mon, Jan 20, 2014 at 10:23 AM, Brian Paul <bri...@vmware.com> wrote: >>> I'm having trouble figuring out how to bypass this and make it call >>> update_vp/fp/gp which appear like they'll actually call >>> pipe->create_fs_state/etc. I see st_link_shader getting called, as >>> expected, which creates the TGSI... but what to do from there? >> >> >> If you were to short-circuit the validation steps above and force the VS/FS >> to get propagated to the driver ASAP, there's a chance the shader wouldn't >> actually do everything that it normally would (ex: invert Y). I don't know >> if that matters to you. > > Not at all. This is for checking various nouveau compiler > optimizations against input shaders. I think that as long as the > shaders passed to the driver remain basically the same, it should > still be useful for comparing emitted code with different (nouveau) > compiler versions. > >> >> In any case, there's no simple solution to this. You'll probably have to >> hack something up. If it turns out simple, maybe we could enable it with a >> debug flag. > > Could you suggest a way for hacking this up? i.e. what functions might > I call from where? I'm definitely having trouble groking the code > paths that cause things to be sent right now. > > Thanks, > > -ilia > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
