From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grigori Goronzy Subject: Fwd: Re: [PATCH] drm/radeon: Adding UVD handle basis fps estimation v2 Date: Fri, 15 Aug 2014 18:46:26 +0200 Message-ID: <53EE3962.1070302@chown.ath.cx> References: <53EE37E2.4020308@chown.ath.cx> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1944942558==" Return-path: Received: from pygmy.kinoho.net (pygmy.kinoho.net [134.0.27.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 4D3D36E190 for ; Fri, 15 Aug 2014 09:46:31 -0700 (PDT) In-Reply-To: <53EE37E2.4020308@chown.ath.cx> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Dri Devel Cc: Peter.Fruehberger@gmail.com, christian.koenig@amd.com List-Id: dri-devel@lists.freedesktop.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1944942558== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GcpsSSc2m1KJe3xt2Vb5WmjGGHE8w3pmO" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GcpsSSc2m1KJe3xt2Vb5WmjGGHE8w3pmO Content-Type: multipart/mixed; boundary="------------030902090700010401020400" This is a multi-part message in MIME format. --------------030902090700010401020400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For reference, I forgot to send to you all. -------- Forwarded Message -------- Subject: Re: [PATCH] drm/radeon: Adding UVD handle basis fps estimation v= 2 Date: Fri, 15 Aug 2014 18:40:02 +0200 From: Grigori Goronzy To: Alex Deucher On 15.08.2014 17:45, Alex Deucher wrote: > Maybe I'm not understanding what you are proposing them. UVD power > states fall into basically 3 categories: >=20 > 1. R6xx/r7xx/evergreen > - single UVD state >=20 > 2. older APUs/NI/SI > - multiple UVD states with different combinations of slck/mclk and uvd = clocks >=20 > 3. CI+ > - hw managed dynamic UVD clocks >=20 > The second category is the problematic one and the only one where the > UVD state selection is a factor. We really need better logic to > determine what sclks/mclk and uvd clks so we know which power state to > select. The logic in the kernel is fine for determining the level of > uvd clks we need, but when post processing is enabled you also have to > take into account the levels of sclk/mclk needed for the 3D engine. >=20 I mean the second category. On most systems, low (uvd_sd, uvd_hd) UVD power states appear to have multiple 3D power levels or a single 3D power level with clocks equal to the highest level in the "performance" power state. However on some systems, low UVD power states only have a single 3D power level that is noticeably slower than the maximum "performance" state power level. It's mostly these systems that are problematic, as far as I can see. My proposal is to detect this condition and disable usage of the low UVD power states (by default at least) on affected systems. Other systems can dynamically choose an UVD power state according to active streams. Of course this affects power consumption, but at least avoids the issue of crippled 3D performance in some scenarios. I don't see a good way to automatically select an appropriate UVD power state according to 3D load. Video post processing isn't the only possible scenario that needs a lot of 3D performance. There really isn't much that can be done. What do you think about this? Grigori > Alex >=20 >> >> Grigori >> >>> Alex >>> >>> >>>> Best regards >>>> Grigori >>>> >>>>> Regards, >>>>> Christian. >>>>> >>>>> Am 15.08.2014 um 15:21 schrieb Marco Benatto: >>>>>> Hey all, >>>>>> >>>>>> I also had a talk with Alex yesterday about post-processing issues= >>>>>> when using dynamic UVD profiles and a chamge on CS ioctl >>>>>> including a flag to let user mode driver tell to the kernel which >>>>>> performance requirement it wants for post processing. A commom >>>>>> point for both discussion is to stablish the default values for th= ese >>>>>> profiles, but probably this ioctl change would be more impacting/c= omplex >>>>>> to implement than a sysfs entry. >>>>>> >>>>>> If a sysfs entry is anough for now I can handle the code to create= it >>>>>> and, with your help, the code to setup the UVD profile requested >>>>>> through it. >>>>>> >>>>>> Is there any suggestion? >>>>>> >>>>>> Thanks all for your help, >>>>>> >>>>>> >>>>>> On Fri, Aug 15, 2014 at 5:48 AM, Christian K=C3=B6nig >>>>>> > wrote= : >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> to make a long story short every time I watch a movie my lapto= p >>>>>> start to heat up because we always select the standard UVD pow= er >>>>>> profile without actually measuring if that is necessary. >>>>>> >>>>>> Marco came up with a patch that seems to reliable measure the = fps >>>>>> send down to the kernel and so together with knowing the frame= >>>>>> size of the video should allow us to select the right UVD powe= r >>>>>> profile. >>>>>> >>>>>> The problem is that Alex (unnoticed by me) completely disabled= >>>>>> selecting the UVD profiles because of some issues with advance= d >>>>>> post processing discussed on IRC. The problem seems to be that= the >>>>>> lower UVD profiles have a to low SCLK/MCLK to handle the 3D lo= ad >>>>>> that comes with scaling, deinterlacing etc... >>>>>> >>>>>> I unfortunately don't have time for it, cause this only affect= s >>>>>> the hardware generations R600-SI and not the newest one CIK. S= o >>>>>> could you guys stick together and come up with a solution? >>>>>> Something like a sysfs entry that let's us select the minimum = UVD >>>>>> power level allowed? >>>>>> >>>>>> I think Marco is happy to come up with a patch, we just need t= o >>>>>> know what's really needed and what should be the default value= s. >>>>>> I'm happy to review everything that comes out of it, just don'= t >>>>>> have time to do it myself. >>>>>> >>>>>> Happy discussion and thanks in advance, >>>>>> Christian. >>>>>> >>>>>> Am 12.08.2014 um 15:05 schrieb Alex Deucher: >>>>>> >>>>>> On Tue, Aug 12, 2014 at 6:00 AM, Christian K=C3=B6nig >>>>>> >= wrote: >>>>>> >>>>>> Am 11.08.2014 um 16:52 schrieb Alex Deucher: >>>>>> >>>>>> On Mon, Aug 11, 2014 at 5:08 AM, Christian K=C3=B6= nig >>>>>> >>>>> > wrote: >>>>>> >>>>>> Am 07.08.2014 um 21:43 schrieb Alex Deucher: >>>>>> >>>>>> On Thu, Aug 7, 2014 at 11:32 AM, Christian= K=C3=B6nig >>>>>> >>>>> > wrote: >>>>>> >>>>>> Am 07.08.2014 um 16:32 schrieb Alex De= ucher: >>>>>> >>>>>> On Thu, Aug 7, 2014 at 7:33 AM, >>>>>> Christian K=C3=B6nig >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> From: Marco A Benatto >>>>>> >>>>> > >>>>>> >>>>>> Adding a Frames Per Second >>>>>> estimation logic on UVD handle= s >>>>>> when it has being used. This >>>>>> estimation is per handle basis= >>>>>> and will help on DPM profile >>>>>> calculation. >>>>>> >>>>>> v2 (chk): fix timestamp type, = move >>>>>> functions around and >>>>>> cleanup code a b= it. >>>>>> >>>>>> Will this really help much? I tho= ught >>>>>> the problem was mainly due to >>>>>> sclk and mclk for post processing.= >>>>>> >>>>>> >>>>>> It should at least handle the UVD side= for >>>>>> upclocking when you get a >>>>>> lot >>>>>> of >>>>>> streams / fps. And at on my NI the pat= ch >>>>>> seems to do exactly that. >>>>>> >>>>>> Switching sclk and mclk for post >>>>>> processing is a different task, and I >>>>>> actually have no idea what to do with = them. >>>>>> >>>>>> At this point we always choose the plain U= VD >>>>>> state anyway so this >>>>>> patch would only take effect if we re-enab= led >>>>>> the dynamic UVD state >>>>>> selection. >>>>>> >>>>>> >>>>>> Hui? I thought we already re-enabled the dynam= ic >>>>>> UVD state selection, but >>>>>> double checking this I found it disabled again= =2E >>>>>> >>>>>> What was the problem with that? Looks like I >>>>>> somehow missed the >>>>>> discussion >>>>>> around it. >>>>>> >>>>>> We did, but after doing so a number of people >>>>>> complained about a >>>>>> regression on IRC because when apps like xmbc enab= led >>>>>> post processing, >>>>>> performance went down. >>>>>> >>>>>> >>>>>> That's strange, from my experience the different UVD >>>>>> performance states only >>>>>> affect UVDs dclk/vclk, not sclk/mclk. I need to get th= e >>>>>> DPM dumps to >>>>>> confirms this. >>>>>> >>>>>> The sclks and mclks are usually different as well, especia= lly >>>>>> on APUs. >>>>>> I can send you some examples. >>>>>> >>>>>> You not off hand remember who complained on IRC? Findi= ng >>>>>> something in the >>>>>> IRC logs is like searching for a needle in a haystack.= >>>>>> >>>>>> I don't remember off hand. I think zgreg was involved in = some >>>>>> of the >>>>>> discussions. >>>>>> >>>>>> Alex >>>>>> >>>>>> Thanks, >>>>>> Christian. >>>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> Christian. >>>>>> >>>>>> >>>>>> For the post processing, we probably need = a >>>>>> hint we can >>>>>> pass to the driver in the CS ioctl to deno= te >>>>>> what state we need. >>>>>> Although if we did that, this could would >>>>>> largely be moot. That said, >>>>>> newer asics support dynamic UVD clocks so = we >>>>>> really only need >>>>>> something like that for older asics and I >>>>>> guess VCE. >>>>>> >>>>>> Alex >>>>>> >>>>>> Christian. >>>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>> Signed-off-by: Marco A Benatto= >>>>>> >>>>> > >>>>>> Signed-off-by: Christian K=C3=B6= nig >>>>>> >>>>> > >>>>>> --- >>>>>> >>>>>> drivers/gpu/drm/radeon/radeon= =2Eh >>>>>> | 10 ++++++ >>>>>> >>>>>> drivers/gpu/drm/radeon/radeon= _uvd.c >>>>>> | 64 >>>>>> ++++++++++++++++++++++++++++++= +++---- >>>>>> 2 files changed, 68 >>>>>> insertions(+), 6 deletions(-) >>>>>> >>>>>> diff --git >>>>>> a/drivers/gpu/drm/radeon/radeo= n.h >>>>>> b/drivers/gpu/drm/radeon/radeo= n.h >>>>>> index 9e1732e..e92f6cb 100644 >>>>>> --- a/drivers/gpu/drm/radeon/r= adeon.h >>>>>> +++ b/drivers/gpu/drm/radeon/r= adeon.h >>>>>> @@ -1617,6 +1617,15 @@ int >>>>>> radeon_pm_get_type_index(struc= t >>>>>> radeon_device >>>>>> *rdev, >>>>>> #define >>>>>> RADEON_UVD_STACK_SIZE (1024*1= 024) >>>>>> #define RADEON_UVD_HEAP_S= IZE >>>>>> (1024*1024) >>>>>> >>>>>> +#define RADEON_UVD_FPS_EVENTS= _MAX 8 >>>>>> +#define RADEON_UVD_DEFAULT_FP= S 60 >>>>>> + >>>>>> +struct radeon_uvd_fps { >>>>>> + uint64_t timest= amp; >>>>>> + uint8_t event_= index; >>>>>> + uint8_t >>>>>> events[RADEON_UVD_FPS_EVENTS_= MAX]; >>>>>> +}; >>>>>> + >>>>>> struct radeon_uvd { >>>>>> struct radeon_bo >>>>>> *vcpu_bo; >>>>>> void >>>>>> *cpu_addr; >>>>>> @@ -1626,6 +1635,7 @@ struct >>>>>> radeon_uvd { >>>>>> struct drm_file >>>>>> *filp[RADEON_MAX_UVD_HANDLES]= ; >>>>>> unsigned >>>>>> img_size[RADEON_MAX_UVD_HAND= LES]; >>>>>> struct delayed_wor= k >>>>>> idle_work; >>>>>> + struct radeon_uvd_fps >>>>>> fps_info[RADEON_MAX_UVD_HANDL= ES]; >>>>>> }; >>>>>> >>>>>> int radeon_uvd_init(struc= t >>>>>> radeon_device *rdev); >>>>>> diff --git >>>>>> a/drivers/gpu/drm/radeon/radeo= n_uvd.c >>>>>> b/drivers/gpu/drm/radeon/radeo= n_uvd.c >>>>>> index 6bf55ec..ef5667a 100644 >>>>>> --- >>>>>> a/drivers/gpu/drm/radeon/radeo= n_uvd.c >>>>>> +++ >>>>>> b/drivers/gpu/drm/radeon/radeo= n_uvd.c >>>>>> @@ -237,6 +237,51 @@ void >>>>>> radeon_uvd_force_into_uvd_segm= ent(struct >>>>>> radeon_bo *rbo) >>>>>> rbo->placement.lpf= n =3D >>>>>> (256 * 1024 * 1024) >> PAGE_SH= IFT; >>>>>> } >>>>>> >>>>>> +static void >>>>>> radeon_uvd_fps_clear_events(st= ruct >>>>>> radeon_device *rdev, >>>>>> int >>>>>> idx) >>>>>> +{ >>>>>> + struct radeon_uvd_fps = *fps >>>>>> =3D &rdev->uvd.fps_info[idx]; >>>>>> + unsigned i; >>>>>> + >>>>>> + fps->timestamp =3D jif= fies_64; >>>>>> + fps->event_index =3D 0= ; >>>>>> + for (i =3D 0; i < >>>>>> RADEON_UVD_FPS_EVENTS_MAX; i++= ) >>>>>> + fps->events[i]= =3D 0; >>>>>> +} >>>>>> + >>>>>> +static void >>>>>> radeon_uvd_fps_note_event(stru= ct >>>>>> radeon_device *rdev, >>>>>> int >>>>>> idx) >>>>>> +{ >>>>>> + struct radeon_uvd_fps = *fps >>>>>> =3D &rdev->uvd.fps_info[idx]; >>>>>> + uint64_t timestamp =3D= >>>>>> jiffies_64; >>>>>> + unsigned rate =3D 0; >>>>>> + >>>>>> + uint8_t index =3D >>>>>> fps->event_index++; >>>>>> + fps->event_index %=3D >>>>>> RADEON_UVD_FPS_EVENTS_MAX; >>>>>> + >>>>>> + rate =3D div64_u64(HZ,= >>>>>> max(timestamp - fps->timestamp= , >>>>>> 1ULL)); >>>>>> + >>>>>> + fps->timestamp =3D tim= estamp; >>>>>> + fps->events[index] =3D= >>>>>> min(rate, 120u); >>>>>> +} >>>>>> + >>>>>> +static unsigned >>>>>> radeon_uvd_estimate_fps(struct= >>>>>> radeon_device *rdev, >>>>>> int >>>>>> idx) >>>>>> +{ >>>>>> + struct radeon_uvd_fps = *fps >>>>>> =3D &rdev->uvd.fps_info[idx]; >>>>>> + unsigned i, valid =3D = 0, >>>>>> count =3D 0; >>>>>> + >>>>>> + for (i =3D 0; i < >>>>>> RADEON_UVD_FPS_EVENTS_MAX; i++= ) { >>>>>> + /* We should >>>>>> ignore zero values */ >>>>>> + if (fps->event= s[i] >>>>>> !=3D 0) { >>>>>> + count = +=3D >>>>>> fps->events[i]; >>>>>> + valid+= +; >>>>>> + } >>>>>> + } >>>>>> + >>>>>> + if (valid > 0) >>>>>> + return count /= valid; >>>>>> + else >>>>>> + return >>>>>> RADEON_UVD_DEFAULT_FPS; >>>>>> +} >>>>>> + >>>>>> void >>>>>> radeon_uvd_free_handles(struct= >>>>>> radeon_device *rdev, struct >>>>>> drm_file *filp) >>>>>> { >>>>>> int i, r; >>>>>> @@ -419,8 +464,10 @@ static in= t >>>>>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo, >>>>>> >>>>>> /* create or decod= e, >>>>>> validate the handle */ >>>>>> for (i =3D 0; i < >>>>>> RADEON_MAX_UVD_HANDLES; ++i) {= >>>>>> - if >>>>>> (atomic_read(&p->rdev->uvd.han= dles[i]) >>>>>> =3D=3D handle) >>>>>> + if >>>>>> (atomic_read(&p->rdev->uvd.han= dles[i]) >>>>>> =3D=3D handle) >>>>>> { >>>>>> + >>>>>> radeon_uvd_fps_note_event(p->= rdev, i); >>>>>> re= turn 0; >>>>>> + } >>>>>> } >>>>>> >>>>>> /* handle not foun= d >>>>>> try to alloc a new one */ >>>>>> @@ -428,6 +475,7 @@ static int= >>>>>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo, >>>>>> if >>>>>> (!atomic_cmpxchg(&p->rdev->uvd= =2Ehandles[i], >>>>>> 0, >>>>>> handle)) { >>>>>> >>>>>> p->rdev->uvd.filp[i] =3D p->fi= lp; >>>>>> >>>>>> p->rdev->uvd.img_size[i] =3D i= mg_size; >>>>>> + >>>>>> radeon_uvd_fps_clear_events(p= ->rdev, >>>>>> i); >>>>>> re= turn 0; >>>>>> } >>>>>> } >>>>>> @@ -763,7 +811,7 @@ int >>>>>> radeon_uvd_get_destroy_msg(str= uct >>>>>> radeon_device >>>>>> *rdev, int ring, >>>>>> static void >>>>>> radeon_uvd_count_handles(struc= t >>>>>> radeon_device *rdev, >>>>>> >>>>>> unsigned *sd, unsigned = *hd) >>>>>> { >>>>>> - unsigned i; >>>>>> + unsigned i, fps_rate =3D= 0; >>>>>> >>>>>> *sd =3D 0; >>>>>> *hd =3D 0; >>>>>> @@ -772,10 +820,13 @@ static v= oid >>>>>> radeon_uvd_count_handles(struc= t >>>>>> radeon_device *rdev, >>>>>> if >>>>>> (!atomic_read(&rdev->uvd.handl= es[i])) >>>>>> co= ntinue; >>>>>> >>>>>> - if >>>>>> (rdev->uvd.img_size[i] >=3D 72= 0*576) >>>>>> - ++(*hd= ); >>>>>> - else >>>>>> - ++(*sd= ); >>>>>> + fps_rate =3D >>>>>> radeon_uvd_estimate_fps(rdev, = i); >>>>>> + >>>>>> + if >>>>>> (rdev->uvd.img_size[i] >=3D 72= 0*576) { >>>>>> + (*hd) = +=3D >>>>>> fps_rate > 30 ? 1 : 2; >>>>>> + } else { >>>>>> + (*sd) = +=3D >>>>>> fps_rate > 30 ? 1 : 2; >>>>>> + } >>>>>> } >>>>>> } >>>>>> >>>>>> @@ -805,6 +856,7 @@ void >>>>>> radeon_uvd_note_usage(struct >>>>>> radeon_device >>>>>> *rdev) >>>>>> set_clocks &=3D >>>>>> schedule_delayed_work(&rdev->u= vd.idle_work, >>>>>> >>>>>> msecs_to_jiffies(UVD_IDLE_TIME= OUT_MS)); >>>>>> >>>>>> + >>>>>> if >>>>>> ((rdev->pm.pm_method =3D=3D >>>>>> PM_METHOD_DPM) && >>>>>> rdev->pm.dpm_enabled) { >>>>>> unsigned h= d =3D >>>>>> 0, sd =3D 0; >>>>>> >>>>>> radeon_uvd_count_handles(rdev,= >>>>>> &sd, &hd); >>>>>> -- >>>>>> 1.9.1 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Marco Antonio Benatto >>>>>> Linux user ID:#506236 >>>>> >>>> >>>> >> >> --------------030902090700010401020400 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNC QUVCQWdBR0JRSlQ3amZpQUFvSkVPcG1ZRThTZjhIMmg1TVFBTXdaMlZ2dUR5NUh2SU9XanVB OG9qOFMKZmFwWnoxWDFQdHFLTGlkUTVlZUo4VDR1TDA0T0JsWVAvSkFxR1dKODgzT2Vob1VO QkRRQy81anlodkZlK2N5NgpKcWRSOXNpZExpMys0RHUwSTZUTUFIay83Nlc3TTBlMEZIejNO WEo2TEF0TEtiNUp0VzFac3d4a01LN2tTTTlCCkhCQnFNMzE1cnkzSHh1MS9GbVExbWdoeWlx dS82bEI2ZUNWOTR1ZkVUSGhQcE5pRzFCLys3VG5iT01zZ1FreDIKQXFZaEM2bVhaZjNrdWgy TGJqalV6dld5RkNvQVA2YS9IaGVaaHFscndSZm14QlNBYS91V0pFNFc5Wklzb096RAp6Nk5C V3FRaTVsWXErb2RqaWdlVFdTclJZZWw3OTFCSHorUkFKNVBIaWZXdjdkLzJvWjZ1dXBBdnBC cW1RNWQvClpCWVhwbjdLVUFKNE04TDE5bkY0RXk3TW1FVWFFdi9tTXFocFA0NndPeEVsSkZp NWU3Wm0xbHQwWWRINHZoM0kKVHJqaU81aCtnY1RYRjR0aVFWV2hidGVUM2Q5dFhvNWdCSnRU cWQrbTZmck5qTXJiWFo0WTgvRXFqV1RFV1RVWgorbm1yeFdMTmRlamtkMmxrSUczUnlGTENZ cWpiRmtkS3RwSkFDdFRjMDVONlRWU3l3MTBCVWN3bWY4ckV5RWtzCk1XOVIxOEx0RzdGei9w OEdEZlFnays0QUZMdlVVTitXY1FYMXllbjZpQkRoQkJWa2RKYkF3Q2lzNWtVOTNMdHEKZFUy aHBsN3BPUWEzVStOOUhjSmh2aDl5alB5V0Q0a1dUaEREeXBTOXJ2MUllVjV5Zkg4RDZ0MHcr R2pEcWk1bApKWHZpQVE5RFZLdGhkL3hOQitGaAo9a2VscgotLS0tLUVORCBQR1AgU0lHTkFU VVJFLS0tLS0KCg== --------------030902090700010401020400-- --GcpsSSc2m1KJe3xt2Vb5WmjGGHE8w3pmO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT7jliAAoJEOpmYE8Sf8H2hkAP/ic/ySV+trNpKn0heWLlHAQc NNy7t7T2A8/6sg62A7F23mgs89eeHrNI9DOS/vTnP+hov0zwy9dchzq8hpkUytZ6 IGjZYZLc8KZ4lpajBX3EpZ1h2Q8Dn6jM9MuJ/kGpF/ZuRiCS94D0TE4jecc0qbT7 xIX80Dc5kCHP727ezpXnljMVh1B/0WhOhT9UpKrtM6Z/lezwR5qM8HttKcPMxLxf R4XXnEOjOXJq2UaTNAfHgsN3AOrkvr121DPRCw87bDqbzanw+D5et9WVZ9zsVLna x/Szm4hAP6odloNssA6yiyk/3Vi+9bppj2Q+lWcC6BCeBbRVwG/PJhmLOzBq76Mz 3GI06NVkfyuJEkJctXyHOfVNTqus16QMZdcSXzFXqHIfE11/dZ6bk+w56JyabElI aSOn1pnsDK2bto7mzGSKpbwhK2I2uhu945UtPAuGW0tzK2YmYltRM8K5+1fH42Zy B+A36ymbtUCzECwx+Rm793yk1vDkGvW4r5EZBl99lhwXxp3wRD9X/BwvQooDvY+q zGci8+gR5WIYwUcn953efAUsJ0MtALt0arDfIyFuP9kFjFPyXPBgcBd1bFNNyr7Y 8pkfSxihK50UnFu4pHS40SjWgUTtskANnPRP3KJQ36w3hXO01XWAaVzAwgxIZ+4n LMP6zNLXOqP5Rq6vX+F5 =0Zzr -----END PGP SIGNATURE----- --GcpsSSc2m1KJe3xt2Vb5WmjGGHE8w3pmO-- --===============1944942558== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1944942558==--