[Mesa-dev] [PATCH 02/14] i965: Generalize fs_generator further
Jordan Justen
jljusten at gmail.com
Thu Oct 30 00:19:32 PDT 2014
On Wed, Oct 29, 2014 at 5:30 PM, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Tue, Oct 28, 2014 at 5:30 PM, Matt Turner <mattst88 at gmail.com> wrote:
>> On Tue, Oct 28, 2014 at 3:59 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>>>> - assert(stage == MESA_SHADER_FRAGMENT);
>>>>
>>>> I like removing these asserts from the function bodies, but I'm
>>>> confused why you're doing it. The VS isn't going to call
>>>> fire_fb_write, or emit a derivative instruction.
>>>
>>> Oh, you're actually removing the stage member entirely. Isn't that
>>> useful to have?
>>>
>>> Maybe I need to keep reading the series..
>>
>> Okay, still don't understand. It seems like your objective in patch 3
>> is to be able to print things other than "fragment" under various
>> INTEL_DEBUG=... settings. Wouldn't it be simpler to contain that logic
>> in the generator using the stage member -- which would be nice to have
>> for assertions anyway?
>
> What I was trying to do here was to make the generator independent of
> the shader stage. It receives a cfg_t and spits out assembly and
> doesn't care about what stage it may be. It simplifies the generator
> a little and passing in the debug name means that the generator
> doesn't have to know about blorp, for example. I think my biggest
> problem with losing the asserts is that they protect casts of
> prog_data to brw_wm_prog_data (except for the one in
> generate_assembly), but those casts only happens in fs specific
> opcodes.
>
> Either way, I'm not attached to this change, we can put stage back in.
Hmm. I know we talked about removing the stage var on Monday.
It seemed fine then, but I guess I wasn't thinking about how we'd lose
the asserts.
I'm also not yet sure that we won't find a use for stage in the
generator. Maybe we could hold off on this until we have all the other
stages generating scalar code? (I am actually currently using stage in
one cs patch.)
-Jordan
More information about the mesa-dev
mailing list