[Piglit] [PATCH] fbo-framework: check for ARB_framebuffer_object

[Ilia Mirkin]

On Mon, Feb 10, 2014 at 10:23 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 02/10/2014 02:06 AM, Ilia Mirkin wrote:
>> On Thu, Feb 6, 2014 at 1:43 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Sun, Feb 2, 2014 at 8:45 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Thu, Jan 30, 2014 at 2:36 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>> If we just blindly call glBindFramebuffer, that will cause the piglit
>>>>> test to skip. Make sure that ARB_framebuffer_object is supported first.
>>>>
>>>> BTW, an alternative is to flip it to use EXT_fbo (i.e.
>>>> glBindFramebufferEXT & co), but I don't know if I can just do that and
>>>> not suffer some sort of consequence. I'm unfortunately not very
>>>> familiar with all these exttensions, and esp how it's all used in
>>>> piglit.
>>>
>>> ping? would be nice to make it possible to run piglit on nv30/nv40 cards...
>>
>> ping again?
>>
>> When I brought this up on IRC, the responses fell into the following categories:
>
> I wasn't on the IRC discussion, but...
>
>> (a) Make nv40 support ARB_fbo, how hard can it be... Perhaps it can be
>> done reasonably (I don't think so), but not related to the framework
>> trying to use ARB_fbo without checking for it.
>
> Agreed.
>
>> (b) Change the piglit dispatch logic to fall back on the EXT version.
>> There were counter-arguments saying that the EXT version was somehow
>> different. I don't know anything about this, and am not in a position
>> to decide one way or another which is right.
>> (c) Switch to using EXT always. Similar to (b) -- I'm not sure what
>> effect that'll have on things.
>
> The EXT is different in a number of ways, but I don't know that any of
> those ways actually matter for the way the -fbo option operates.  The
> main differences are that ARB relaxes some restrictions (or allows them
> to be relaxed), it changes the object sharing rules, and it requires
> that object names be Gen'ed before using.
>
> The only functions that differ between the two extensions is
> glBindFramebuffer and glBindRenderbuffer.  Piglit dispatch (or expoxy)
> MUST NOT switch these functions behind the test's back.  However, it
> shouldn't be hard for the -fbo framework to pick EXT vs. non-EXT for
> these two functions at run-time.
>
>> The reality is that _today_ the fbo framework (or at least this bit of
>> it) uses ARB_fbo. Perhaps there can be some other day when the
>> fallbacks are such that it doesn't and it's all tested and so on. But
>> that is not today.
>>
>> So any objections to this change going in, which fixes the fbo
>> framework to accurately represent that it uses an ARB_fbo call and
>> thus must have the extension? (And if it ends up returning false, it
>> falls back on the winsys framework, as if -fbo wasn't passed in.) If I
>> don't hear anything in the next couple of days, I'll check this in.
>
> This looks fine to me, but some follow-up work should occur.

Happy to do it, but it should hopefully be clear by now that my
talents lie in the "writing code" department, not the "knowing how
opengl works" department. Just tell me what you want, and (within
reason) I'll make it happen. Most importantly, let me know what
testing should be done to validate those changes. The only thing I
hate more than broken test frameworks is breaking them myself :)

Should I just make the -fbo framework always use EXT? Use it when ARB
isn't available? (From a pure software standpoint, it seems like it'd
be nice for a framework to always do the same thing, which in my mind
makes the always-use-EXT solution better. But it's likely I don't have
the full view of things.)

>
> Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>

Thanks! I'll push this, or drop it in favor of whatever you propose
above, depending on... what you propose :)

  -ilia