[Mesa-dev] mesa/st: how to force glLinkProgram to create/translate the program?
Ilia Mirkin
imirkin at alum.mit.edu
Fri Feb 7 10:05:19 PST 2014
Cool. Do you think something like this is check-in-able behind a
ST_PRECOMPILE=1 env var (or something that fits well into the current
env var scheme, dunno what it would be)?
On Fri, Feb 7, 2014 at 12:46 PM, Marek Olšák <maraeo at gmail.com> wrote:
> FYI, I found the patch which compiles some shader variants in glLinkProgram:
>
> http://cgit.freedesktop.org/~mareko/mesa/commit/?h=precompile&id=8dc586297e4902dfc14cf8001b8202db4fdc9447
>
> Marek
>
> On Tue, Jan 21, 2014 at 12:56 AM, Marek Olšák <maraeo at gmail.com> wrote:
>> 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 <imirkin at alum.mit.edu> wrote:
>>> On Mon, Jan 20, 2014 at 10:23 AM, Brian Paul <brianp at 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 at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list