https://bugs.freedesktop.org/show_bug.cgi?id=92687
Eduardo Lima Mitev <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected], | |[email protected], | |[email protected] --- Comment #2 from Eduardo Lima Mitev <[email protected]> --- 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.
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
