Fix potential issues if state-tracker passes in garbage in templ->next
ptr.
See:
https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++
src/gallium/drivers/i915/i915_resource_buffer.c
I don't think that's really a good idea. Zero-initializing things is one
thing, but explicitly overwrite things which were given to the driver by
the st is something else.
(I'm not even sure how it works if the driver always overwrites this to
zero no matter what. Well I suppose those are the conse
the interface is a bit hand-wavey, ie. w/ things like prsc->screen
overwriten by driver.. I guess I can try to track down the
screen->resource_create() callers that aren't zero-init'ing the templ,
although the # of callers seemed much higher than # of drivers
BR,
-R
On Mon, Oct 3, 2016 at 12:27
In an ideal world everybody would zero-intialize the template I suppose
- then it would easily survive such interface changes.
I thought though there shouldn't be many callers but I might have been
wrong about this...
Roland
Am 03.10.2016 um 18:48 schrieb Rob Clark:
> the interface is a bit hand
There are a lot of callers for ->resource_create() and friends..
although I suspect it is a small subset that don't zero-init. But
I'll have to go through all the call sites and check, but I didn't yet
find time yet to do that today..
I don't want to annoy too many folks w/ broken piglits, so if
Sounds reasonable to me.
Roland
Am 04.10.2016 um 01:44 schrieb Rob Clark:
> There are a lot of callers for ->resource_create() and friends..
> although I suspect it is a small subset that don't zero-init. But
> I'll have to go through all the call sites and check, but I didn't yet
> find time ye
BTW, I think fixing this in drivers is better, because the number of
resource_create implementations is limited and they are easy to find.
Marek
On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger wrote:
> Sounds reasonable to me.
>
> Roland
>
> Am 04.10.2016 um 01:44 schrieb Rob Clark:
>> There
I know we do at least have an etnaviv gallium driver hanging out there
waiting to be merged, and don't want to cause them unnecessary rebase
pain.. so if $num_of_callsites_to_fix < $num_of_gallium_drivers, I
don't mind fixing it at the call sites.. but I'll have to audit a
whole bunch of call-sites
The reason I don't like this isn't really the number of callers, rather
that the driver is going actively against what the state tracker told it
to do. But I'm not strongly opposed to this, since effectively
restricting the next field to be only valid if the resource is created
externally might be
On 04/10/16 01:53 AM, Roland Scheidegger wrote:
> In an ideal world everybody would zero-intialize the template I suppose
> - then it would easily survive such interface changes.
As long as there are no fields where 0 isn't a safe value...
What's needed is an explicit definition of whether it's t
Am 04.10.2016 um 03:16 schrieb Michel Dänzer:
> On 04/10/16 01:53 AM, Roland Scheidegger wrote:
>> In an ideal world everybody would zero-intialize the template I suppose
>> - then it would easily survive such interface changes.
>
> As long as there are no fields where 0 isn't a safe value...
That
Hi,
as of writing, there doesn't seem to be a concensus on the fix.
Could one be found for Mesa 13 ? Gallium nine is apparently broken
except on radeonsi which zeros out the next field... It'd need either the
proposed patch of this thread merged, or to zero the next field everywhere.
I guess oth
Please memset in state tracker. Most of the other state trackers do
this, although I haven't finished auditing yet.
BR,
-R
On Fri, Oct 7, 2016 at 1:56 AM, Axel Davy wrote:
> Hi,
>
> as of writing, there doesn't seem to be a concensus on the fix.
> Could one be found for Mesa 13 ? Gallium nine i
13 matches
Mail list logo
