-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
> Thanks to Intel QA providing a few piglit cases to test the API, this has
> had a cursory test and identified the silly cases of using the wrong
> lookup functions.
>
> The ugly part is that I've used 3 different driver functions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
> On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul wrote:
>> Chris Wilson wrote:
>>> Please review and include in 7.7! :)
>> This will go into Mesa 7.8, actually.
>>
>> I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches
>>
Chris Wilson wrote:
> On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul wrote:
>> Chris Wilson wrote:
>>> Please review and include in 7.7! :)
>> This will go into Mesa 7.8, actually.
>>
>> I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches
>> misnumbered or did 2/4 not get posted?
>
> As
On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul wrote:
> Chris Wilson wrote:
> > Please review and include in 7.7! :)
>
> This will go into Mesa 7.8, actually.
>
> I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches
> misnumbered or did 2/4 not get posted?
As Michael pointed out, the c
On Fri, 2010-03-05 at 07:48 -0700, Brian Paul wrote:
> Chris Wilson wrote:
> > Thanks to Intel QA providing a few piglit cases to test the API, this has
> > had a cursory test and identified the silly cases of using the wrong
> > lookup functions.
> >
> > The ugly part is that I've used 3 differe
Chris Wilson wrote:
> Thanks to Intel QA providing a few piglit cases to test the API, this has
> had a cursory test and identified the silly cases of using the wrong
> lookup functions.
>
> The ugly part is that I've used 3 different driver functions to handle
> each of the 3 object variants - th
Thanks to Intel QA providing a few piglit cases to test the API, this has
had a cursory test and identified the silly cases of using the wrong
lookup functions.
The ugly part is that I've used 3 different driver functions to handle
each of the 3 object variants - the alternative would be pass in a
After a hiatus, I'm back once more with support for APPLE_object_purgeable
on Intel hardware. The changes from last time are a rebase and renaming of
the driver hooks from
->ObjectPurgeable_RenderObject
to
->RenderObjectPurgeable.
I think that addresses the one outstanding issue from the las
Chris,
It looks like this extension depends on the drm_intel_bo_madvise()
function which isn't in a released version of libdrm yet. Correct?
If so, I'd like to hold off on applying this patch to Mesa until
there's a new libdrm.
-Brian
-
