[Mesa-dev] Merging translate and unnormalized-coords-hint?

Luca Barbieri luca at luca-barbieri.com
Mon Aug 16 07:20:55 PDT 2010


> Is this a fair summary of the intentions of the change?
It's an excellent summary.

> In this model, the state tracker would query the driver explicitly to
> find out what normalization to use for internal rendering, and pass
> through the API constraints otherwise.
What do you mean exactly by "query"? A new function pointer to pipe_screen?
This obviously must be a per-resource attribute, so just a cap won't work.

There should be no need to compute this on-demand, so I think a flag
works fine, and adds less clutter to both the interface and drivers,
as well as being faster.
Any reason to not use a pipe_resource field/flag for this?

> To represent all possibilities you'd need two flags, one for normalized
> and one for unnormalized, such that OpenCL could set (NORMALIZED |
> UNNORMALIZED).
>
> Would that work for your needs?
Yes.

I was aware of the issues and did it that way to create the smallest
possible patch that would deliver the functionality, especially
considering that this only impacts old hardware.

For instance, we can get away with just one flag in state_tracker ->
driver because there are only two classes of GPUs:
- the first class (pre-DX10) cares about those flags but doesn't
support any API that would use (NORMALIZED | UNNORMALIZED), i.e.
OpenCL
- the second class (post-DX10) doesn't care about those flags since
the resource layout is not tied to the normalization

That said, if you would prefer a larger, more invasive, but
conceptually cleaner solution, it can surely be done.


More information about the mesa-dev mailing list