On 6/12/12 3:12 PM, Ian Romanick wrote: > On 06/12/2012 02:56 PM, James Jones wrote: >> On 6/12/12 2:47 PM, Ian Romanick wrote: >>> On 06/12/2012 02:35 PM, James Jones wrote: >>>> On 6/12/12 2:25 PM, Ian Romanick wrote: >>>>> From: Ian Romanick<ian.d.roman...@intel.com> >>>>> >>>>> The spec doesn't forbid indirect rendering with OpenGL ES 2.0. >>>>> There's no protocol defined, so it seems impossible that this could >>>>> ever work. >>>>> >>>>> NVIDIA's closed-source driver fails this test. An indirect-rendering >>>>> ES2 context is created. I have not verified whether this context is >>>>> actually usable, or it is garbage. >>>> >>>> Yeah, I didn't test, but in theory it "just works" with the existing >>>> GLX protocol, so I saw no reason to disable it. Since GLX owns the >>>> GL command protocol specification, not GL or GLES, and this extension >>>> is creating contexts using GLX, I see no reason this should be >>>> considered a required error. >>> >>> So... how do commands like glReleaseShaderCompiler, glShaderBinary, and >>> glGetShaderPrecisionFormat, which have no GLX protocol, work? >> >> They work just as good as the subset of GL commands that don't have >> protocol defined today which many implementations (including ours) allow >> contexts to be created for. I'm not saying it's correct that our > > That seems dodgy. :)
We were more worried about regressing existing working apps by downgrading our GL version when we found the bug internally, since no one ever actually complained about the inflated version numbers until very recently. >> implementation currently allows creation of GLES contexts that only >> partially work (or maybe not at all for all I know), but I don't think >> it's necessarily correct to require ALL implementations to fail either. >> Presumably they could have their own in-house protocol in place. >> >> For example, we implement "Beta" protocol for many GL operations >> that don't have ARB-defined protocol, because we have customers that want >> indirect rendering support now and the ARB approval process often drags >> on forever. It only works when using both our client and server, both >> with beta protocol support enabled, but it is a usable solution and >> doesn't violate the spec in any way that I know of. > > Right. I knew you guys did that, and I can't think of anything wrong > with that. That's why I didn't make a similar test for desktop GL. > (see also http://lists.x.org/archives/xorg-devel/2012-June/031602.html). > > I think I'll rework the test to use the context that was created. If > that works, the test will pass. Does that seem like a fair compromise? Yeah, sounds good. Depending on what you actually mean by "use", we'll pass or fail, but that's fair. Thanks, -James nvpublic _______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
