Am 16.02.2015 um 00:36 schrieb Matt Turner: > On Sat, Feb 14, 2015 at 2:33 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 14.02.2015 um 21:12 schrieb Kenneth Graunke: >>> On Saturday, February 14, 2015 04:37:25 PM srol...@vmware.com wrote: >>>> From: Roland Scheidegger <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
