Hi,
I have sent updates for some of the patches, fixing a few dEQP
regressions we found, as well as rebase conflicts.
At this point, we don't have a any piglit or dEQP regression (GLES3 or
GLES31).
I was wondering if we maybe split the series in smaller sets, it would
help review. Like for example, a first set only introducing the new
driver hook to query1, then another set with query2 stuff, then the i965
bits.
Would that help?
BTW, this series continues to be updated at git tree:
https://github.com/Igalia/mesa/tree/internalformat-query2
cheers,
Eduardo
On 02/03/2016 04:36 PM, Eduardo Lima Mitev wrote:
Hi,
This is a patch series adding support for the ARB_internalformat-query2
extension:
https://www.opengl.org/registry/specs/ARB/internalformat_query2.txt
The corresponding bug is being tracked at:
https://bugs.freedesktop.org/show_bug.cgi?id=92687
The patch-set is structured as follows:
* Patches 01 to 10 sets up the stage to query2. It will add a new, generic
driver hook that obsoletes QuerySamplesForFormat, which is removed. But it
doesn't introduce anything related with query2 yet.
* Patches 11 to 62 implement the different individual queries from query2
extension in the frontend (mesa/main), adding validation and helper functions
as needed.
* Patches 63 to 65 activates the extension on i965. Only the queries where the
driver has something to return other than frontend's default value, are
explicitly implemented.
Some implementation notes:
* All the extension's frontend code is in main/formatquery.c, as it was before
for query1. Only that it also handles query2 now.
* As commented above, a new driver hook 'QueryInternalFormat' was added,
replacing the previous one 'QuerySamplesForFormat'.
* A fallback, generic function _mesa_query_internal_format_default() provides
generic implementation and sensible defaults for all queries, for drivers not
implementing query2. Backends that only care about answering some queries, can
call back this function for the other queries where a generic answer is ok.
* For all pnames, the frontend code will do generic validation as per the spec:
check GL profile, version, extensions.
- If the frontend fails basic validation, it will give the corresponding
negative answer, depending on the pname, without going to the driver.
- If the frontend is fully qualified to provide an answer, it will (i.e,
MAX_WIDTH, COLOR_COMPONENTS, etc). Otherwise it will call the driver hook (i.e,
INTERNALFORMAT_PREFERRED).
- For the cases where the query must return full support, caveat support, or
no support; Mesa/main will always call the driver to decide between full or
caveat support (and only answer directly in the case of no-support).
* The last patches in the branch enable support for this extension in i965
backend (drivers/dri/i965/brw_formatquery.c). The backend code only handle
queries where the answer is affected by driver-specific stuff. But by default,
it calls back the frontend function with the default implementations.
* The 64 bits version of the query introduced by this extension
(GetInternalformati64v), was implemented 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.
A git tree of the series can be found at:
https://github.com/Igalia/mesa/tree/internalformat-query2
There is also a series containing piglit tests for this extension, and is
undergoing review right now. A git tree of that branch can be found at:
https://github.com/Igalia/piglit/tree/internalformat-query2
cheers,
Eduardo (on behalf of the team that worked on this)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
