On 17-03-10 11:32:35, Emil Velikov wrote:
On 10 March 2017 at 01:48, Ben Widawsky wrote:
The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is directly
On 17-03-09 18:52:52, Jason Ekstrand wrote:
On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky wrote:
The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is
On 17-03-10 11:34:19, Jason Ekstrand wrote:
On Thu, Mar 9, 2017 at 6:52 PM, Jason Ekstrand wrote:
On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky wrote:
The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what
On Thu, Mar 9, 2017 at 6:52 PM, Jason Ekstrand wrote:
> On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky wrote:
>
>> The idea behind modifiers like this is that the user of GBM will have
>> some mechanism to query what properties the hardware supports for
On 10 March 2017 at 01:48, Ben Widawsky wrote:
> The idea behind modifiers like this is that the user of GBM will have
> some mechanism to query what properties the hardware supports for its BO
> or surface. This information is directly passed in (and stored) so that
> the DRI
On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky wrote:
> The idea behind modifiers like this is that the user of GBM will have
> some mechanism to query what properties the hardware supports for its BO
> or surface. This information is directly passed in (and stored) so that
>
The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is directly passed in (and stored) so that
the DRI implementation can create an image with the appropriate
attributes.
A