[Mesa-dev] [PATCH] mesa: don't enable NV_fragment_program_option with swrast

[Roland Scheidegger]

Am 16.02.2015 um 00:36 schrieb Matt Turner:
> On Sat, Feb 14, 2015 at 2:33 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 14.02.2015 um 21:12 schrieb Kenneth Graunke:
>>> On Saturday, February 14, 2015 04:37:25 PM sroland at vmware.com wrote:
>>>> From: Roland Scheidegger <sroland at vmware.com>
>>>>
>>>> Since dropping some NV_fragment_program opcodes (commits
>>>> 868f95f1da74cf6dd7468cba1b56664aad585ccb, a3688d686f147f4252d19b298ae26d4ac72c2e08)
>>>> we can no longer parse all opcodes necessary for this extension, leading
>>>> to bugs (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D86980&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=WR7M0CMoTs3KQMrLGbBd33mSg7pYv21Om0yOzq27Swg&s=VVYgQUmxDRQ8b-H-36lfDVGUw4SFuqAVM1qfxbB71pc&e= ).
>>>> Hence don't announce support for it in swrast.
>>>> (The rest of the infrastructure ranging from dead opcodes (TXP_NV) to
>>>> parsing condition codes along with the NV_fragment_program_option variable
>>>> in the context could probably nuked too this is just a minimal fix appropriate
>>>> for stable too.)
>>>> ---
>>>>  src/mesa/main/extensions.c | 1 -
>>>>  1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>>>> index 220b220..c94009f 100644
>>>> --- a/src/mesa/main/extensions.c
>>>> +++ b/src/mesa/main/extensions.c
>>>> @@ -511,7 +511,6 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
>>>>     ctx->Extensions.NV_point_sprite = GL_TRUE;
>>>>     ctx->Extensions.NV_texture_env_combine4 = GL_TRUE;
>>>>     ctx->Extensions.NV_texture_rectangle = GL_TRUE;
>>>> -   ctx->Extensions.NV_fragment_program_option = GL_TRUE;
>>>>     ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
>>>>     ctx->Extensions.OES_standard_derivatives = GL_TRUE;
>>>>     ctx->Extensions.TDFX_texture_compression_FXT1 = GL_TRUE;
>>>>
>>>
>>> Nuking this extension would make some compiler work I'm planning to do
>>> easier, so I'd definitely be interested to hear whether you still need
>>> it.
>>>
>>
>> Well, according to the git log specviewperf11 catia test won't run
>> correctly without supporting some bits from NV_program_option and
>> NV_fragment_program2 - obviously the benchmark doesn't care one bit if
>> the extension is actually officially supported by a driver or not.
>> I suspect this is something which we still need to be able to run,
>> though Brian would probably know the definitive answer.
> 
> If we knew specifically what it uses, maybe we can just support that
> instead of the whole extension? Not having to handle the condition
> code bits of the extension would be nice, for instance.
> 

There's definitely some bits around condition codes with IF/ELSE/ENDIF
needed (with NV_fp2/NV_vp3 even), though it seems there's some
differences to our private code there to make it work. Apart from that
I'm not entirely sure. Maybe we could expose it as an ordinary quirk to
make things more obvious but I've never dealt with that viewperf issue.

Roland