On 30/09/15 00:26, Chad Versace wrote:
On Mon 28 Sep 2015, Martin Peres wrote:
On 28/09/15 17:27, Emil Velikov wrote:
Hi all,
On 17 August 2015 at 19:06, Chad Versace wrote:
On Fri 14 Aug 2015, Chris Wilson wrote:
On Thu, Aug 13, 2015 at 09:58:52PM -0700, Kenneth Graunke wrote:
On Thursday
On Mon 28 Sep 2015, Martin Peres wrote:
> On 28/09/15 17:27, Emil Velikov wrote:
> >Hi all,
> >
> >On 17 August 2015 at 19:06, Chad Versace wrote:
> >>On Fri 14 Aug 2015, Chris Wilson wrote:
> >>>On Thu, Aug 13, 2015 at 09:58:52PM -0700, Kenneth Graunke wrote:
> On Thursday, August 13, 2015 02
On 28/09/15 17:27, Emil Velikov wrote:
Hi all,
On 17 August 2015 at 19:06, Chad Versace wrote:
On Fri 14 Aug 2015, Chris Wilson wrote:
On Thu, Aug 13, 2015 at 09:58:52PM -0700, Kenneth Graunke wrote:
On Thursday, August 13, 2015 02:57:20 PM Martin Peres wrote:
On 07/08/15 23:13, Chris Wilso
Hi all,
On 17 August 2015 at 19:06, Chad Versace wrote:
> On Fri 14 Aug 2015, Chris Wilson wrote:
>> On Thu, Aug 13, 2015 at 09:58:52PM -0700, Kenneth Graunke wrote:
>> > On Thursday, August 13, 2015 02:57:20 PM Martin Peres wrote:
>> > > On 07/08/15 23:13, Chris Wilson wrote:
>> > > > intel_upda
On Fri 14 Aug 2015, Chris Wilson wrote:
> On Thu, Aug 13, 2015 at 09:58:52PM -0700, Kenneth Graunke wrote:
> > On Thursday, August 13, 2015 02:57:20 PM Martin Peres wrote:
> > > On 07/08/15 23:13, Chris Wilson wrote:
> > > > intel_update_winsys_renderbuffer_miptree() will release the existing
> > >
On Thu, Aug 13, 2015 at 09:58:52PM -0700, Kenneth Graunke wrote:
> On Thursday, August 13, 2015 02:57:20 PM Martin Peres wrote:
> > On 07/08/15 23:13, Chris Wilson wrote:
> > > intel_update_winsys_renderbuffer_miptree() will release the existing
> > > miptree when wrapping a new DRI2 buffer, so we
On Thursday, August 13, 2015 02:57:20 PM Martin Peres wrote:
> On 07/08/15 23:13, Chris Wilson wrote:
> > intel_update_winsys_renderbuffer_miptree() will release the existing
> > miptree when wrapping a new DRI2 buffer, so we can remove the early
> > release and so prevent a NULL mt dereference sho
On Thursday, August 13, 2015 02:57:20 PM Martin Peres wrote:
> On 07/08/15 23:13, Chris Wilson wrote:
> > intel_update_winsys_renderbuffer_miptree() will release the existing
> > miptree when wrapping a new DRI2 buffer, so we can remove the early
> > release and so prevent a NULL mt dereference sho
On 07/08/15 23:13, Chris Wilson wrote:
intel_update_winsys_renderbuffer_miptree() will release the existing
miptree when wrapping a new DRI2 buffer, so we can remove the early
release and so prevent a NULL mt dereference should importing the new
DRI2 name fail for any reason. (Reusing the old DRI
On 10/08/15 15:26, Chris Wilson wrote:
On Mon, Aug 10, 2015 at 03:18:09PM +0300, Martin Peres wrote:
On 07/08/15 23:13, Chris Wilson wrote:
intel_update_winsys_renderbuffer_miptree() will release the existing
miptree when wrapping a new DRI2 buffer, so we can remove the early
release and so pre
On Mon, Aug 10, 2015 at 03:18:09PM +0300, Martin Peres wrote:
> On 07/08/15 23:13, Chris Wilson wrote:
> >intel_update_winsys_renderbuffer_miptree() will release the existing
> >miptree when wrapping a new DRI2 buffer, so we can remove the early
> >release and so prevent a NULL mt dereference shoul
On 07/08/15 23:13, Chris Wilson wrote:
intel_update_winsys_renderbuffer_miptree() will release the existing
miptree when wrapping a new DRI2 buffer, so we can remove the early
release and so prevent a NULL mt dereference should importing the new
DRI2 name fail for any reason. (Reusing the old DRI
intel_update_winsys_renderbuffer_miptree() will release the existing
miptree when wrapping a new DRI2 buffer, so we can remove the early
release and so prevent a NULL mt dereference should importing the new
DRI2 name fail for any reason. (Reusing the old DRI2 name will result
in the rendering going
13 matches
Mail list logo
