[Mesa-dev] [Bug 92687] Add support for ARB_internalformat_query2

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Dec 23 10:40:25 PST 2015


https://bugs.freedesktop.org/show_bug.cgi?id=92687

Eduardo Lima Mitev <elima at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brianp at vmware.com,
                   |                            |emil.l.velikov at gmail.com,
                   |                            |idr at freedesktop.org,
                   |                            |mattst88 at gmail.com

--- Comment #2 from Eduardo Lima Mitev <elima at igalia.com> ---
I forgot to mention that we implement the 64 bits version of the query
introduced by this extension (GetInternalformati64v), as a wrapper around the
32 bits version. Since only one query really requires the 64 bits API
(MAX_COMBINED_DIMENSIONS), we handle that pname as a special case. For the rest
of queries, we just forward the call to the default, 32 bits version.


Following, there are some initial issues/questions we have been gathering:

* MAX_COMBINED_DIMENSIONS: the spec says "Note that the value returned can be
>= 2^32 and should be queried with the 64-bit query.". In spite of this
"should",  no error is mentioned if you don't use the 64-bit query (even
reading Issues 5 and 8 about this pname). So the conclusion (for now) is that
it is allowed. What it is not clarified is what the non-64-bit query should
return is the value of MAX_COMBINED_DIMENSIONS is greater that 2^32 (NVIDIA
returns 0). It is ok if we return a clamped value? It is better to return 0 as
NVIDIA does (this somehow hints that something is wrong).

i965 specific:

* What known caveat supports do we have in i965? The spec defines this as:

CAVEAT_SUPPORT: the requested capability is supported by the implementation,
but there may be some implementation-specific caveats that make support less
than optimal. For example using the feature may result in reduced performance
(relative to other formats or features), such as software rendering or other
mechanisms of emulating the desired feature. 

* i965 doesn't override GenerateMipmap driver hook. It is using the default 
implementation provided in mesa/main/mipmap.c. Does this mean it has CAVEAT
support for mipmapping? It is software generated, so I have doubts.

* For INTERNALFORMAT_PREFERRED, the driver should return a "preferred" internal
format that is compatible with the one given by the user as argument, and that
has at least the same precision. Currently, what we do is to return the same
internal format that was passed (same as NVidia proprietary), checking that it
has a matching BRW format. For this, we first obtain a mesa_format from the
internal format using a generic type, then call brw_format_for_mesa_format(). I
have a lot of doubts about this.
So the questions are: does this make sense? What would be the criteria to
choose the preferred internal format for i965? I could not trivially find a
case where we have a better candidate than the passed internal format. 

Piglit related:

* There are some pnames that explicitly mention that if a resource is not
supported, the returned value is zero. This is properly implemented on the
query2 implementation, but we would like to test that on the piglit tests. But
there isn't any equivalent pname to get this info (something like
RESOURCE_SUPPORTED). Right now we are checking against
INTERNALFORMAT_SUPPORTED, but this fails on cases where the internalformat is
supported but not for a specific combination of target/internalformat. We are
not sure how to deal with this, because the straightforward solution would be
implement a equivalent to _is_resource_supported on piglit, but that sounds
overkill.

Thanks for the feedback!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151223/01616360/attachment.html>


More information about the mesa-dev mailing list