From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51924C6778D for ; Wed, 12 Sep 2018 18:22:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CA9972087F for ; Wed, 12 Sep 2018 18:22:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="efKXHqc8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA9972087F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728080AbeILX1l (ORCPT ); Wed, 12 Sep 2018 19:27:41 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:36835 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727332AbeILX1l (ORCPT ); Wed, 12 Sep 2018 19:27:41 -0400 Received: by mail-it0-f65.google.com with SMTP id u13-v6so4384618iti.1 for ; Wed, 12 Sep 2018 11:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=F5etB/1CHk5msEDSy26RnpHD7tD4coVQSklM3jfv9dE=; b=efKXHqc8SlwNpfr1JYI2LjOiwbqCE/in5kPbwqjNm/xSd4TRrYriRgW3E7Rar8BRyV u3vRr4V/UHKLS4put7SGEghVHVFbQiH+xDvsfYoQxUnPnw8FW1Y8fbgGij0mSE83OwvN qJ/guUliNbPFgnD+EmkBOThJigna96LsyqUYU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=F5etB/1CHk5msEDSy26RnpHD7tD4coVQSklM3jfv9dE=; b=fpqjhV4Tzz/bMMgUbPnkmm3MPaLkn+C+9dH8zwBr55O0EIth70OpaiXLSMbcmCSqjj qmlPEbrqDxR3rDN6Mb1Pxi6JoydfglpWZ4uPV2bfoX6kwhavrx9WkQqhxdsQZwm0sMct EXojPTddqboX6ccVxrkt3ZxDyXQ/5bQlOwXQDs+EWXnXY1a3Qv2GV4lRXrWg0YTj7u+q YofED/5dXlhe4rvjjnRYPcIeUpgJVi5zWTm3bFG7IAxWEDJmb+6PPCOAbooWaKDK4fEP z6wb3IqmmsKo4Wj3VmvdLsfHaBpQJI74ltLIxIJCh/QZOCLSt/EH2B2mDDfU9D7jTrGe UNnw== X-Gm-Message-State: APzg51CbVltf0WIm4py8bVGVRx2zKk421/IdLfY3m4iT3mQfzih7EkSQ 6Q7Wl03dEbglISRxBbMJXUrJajmFiLy7sLuFtpXZqQ== X-Google-Smtp-Source: ANB0VdYu47d+0MpcyocVoyo7LimnLj1Mn68JoiRvAJfallmPpeKWSPrX2y7kMLCDh+v/lIl+XA+z1+clBxh0pxseuLs= X-Received: by 2002:a24:3507:: with SMTP id k7-v6mr3164914ita.13.1536776517148; Wed, 12 Sep 2018 11:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:bf05:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 11:21:56 -0700 (PDT) X-Originating-IP: [2a02:168:569e:0:3106:d637:d723:e855] In-Reply-To: <20180912135206.GA21008@DESKTOP-E1NTVVP.localdomain> References: <20180823152343.6474-1-brian.starkey@arm.com> <20180823152343.6474-2-brian.starkey@arm.com> <20180831081730.GM21634@phenom.ffwll.local> <20180907124535.GA3461@DESKTOP-E1NTVVP.localdomain> <20180907192626.GA7176@phenom.ffwll.local> <20180910085003.GA36@DESKTOP-E1NTVVP.localdomain> <20180910195325.GC19774@phenom.ffwll.local> <20180912135206.GA21008@DESKTOP-E1NTVVP.localdomain> From: Daniel Vetter Date: Wed, 12 Sep 2018 20:21:56 +0200 X-Google-Sender-Auth: ZQI3y66XGzoo2nDaFmZbnTbO9RA Message-ID: Subject: Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel To: Brian Starkey Cc: dri-devel , Daniel Stone , Dave Airlie , Gustavo Padovan , Maarten Lankhorst , Sean Paul , Linux Kernel Mailing List , Alexandru-Cosmin Gheorghe , Liviu Dudau , Ayan Kumar Halder , Tomasz Figa , "Kristian H . Kristensen" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 12, 2018 at 3:52 PM, Brian Starkey wrote: > On Mon, Sep 10, 2018 at 09:53:25PM +0200, Daniel Vetter wrote: >> >> On Mon, Sep 10, 2018 at 09:50:03AM +0100, Brian Starkey wrote: >>> >>> Hi, >>> >>> On Fri, Sep 07, 2018 at 09:28:44PM +0200, Daniel Vetter wrote: >>> > On Fri, Sep 07, 2018 at 01:45:36PM +0100, Brian Starkey wrote: >>> > > Hi Daniel, >>> > > >>> > > On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote: >>> > > > On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote: >>> > > > > Some formats have a non-integer number of bytes per pixel, which >>> > > > > can't >>> > > > > be handled with the existing 'cpp' field in drm_format_info. To >>> > > > > handle >>> > > > > these formats, add a 'bpp' field, which is only used if cpp[0] == >>> > > > > 0. >>> > > > > >>> > > > > This updates all the users of format->cpp in the core DRM code, >>> > > > > converting them to use a new function to get the bits-per-pixel >>> > > > > for any >>> > > > > format. >>> > > > > >>> > > > > It's assumed that drivers will use the 'bpp' field when they add >>> > > > > support >>> > > > > for pixel formats with non-integer bytes-per-pixel. >>> > > > > >>> > > > > Signed-off-by: Brian Starkey >>> > > > >>> > > > I assume you still require that stuff is eventually aligned to >>> > > > bytes? In >>> > > > that case, can we subsume this into the tile work Alex is doing? >>> > > > It's >>> > > > essentially just another special case of having storage-size units >>> > > > measured in bytes which span more than 1x1 pixel. And I kinda don't >>> > > > want a >>> > > > metric pile of special cases here in the format code, because that >>> > > > just >>> > > > means every driver handles a different subset, with different bugs. >>> > > > -Daniel >>> > > >>> > > Sorry for the delay, been struggling to free some cycles to think >>> > > about this. >>> > > >>> > > I'm not sure how to pull this in with the tiling stuff. In the AFBC >>> > > case then our AFBC superblocks are always nice round numbers (256 >>> > > pixels), and so it does end up being a multiple of bytes. >>> > > >>> > > However, AFBC supports different superblock sizes, so picking just >>> > > one >>> > > doesn't really work out, and putting AFBC in the core format table >>> > > which reflects AFBC doesn't seem good. >>> > > >>> > > We could make something up (e.g. call these formats "tiled" with 2x4 >>> > > tiles, which guarantees a multiple of 8), but it would be an >>> > > arbitrarily-selected lie, which often seems to spell trouble. If we >>> > > did do that, would you re-define cpp as "bytes-per-tile"? Otherwise >>> > > we still need to add a new field anyway. >>> > > >>> > > What's the pile of special cases you're worried about? The helper >>> > > I've >>> > > added here means that drivers which need to care can use one API and >>> > > not implement their own bugs. >>> > >>> > I'm confused ... the new bits-per-pixel stuff you're adding here is for >>> > yuv formats, not afbc. I'm just suggesting we have only 1 way of >>> > describing such formats that need more descriptive power than cpp, >>> > whether >>> > they have some kind of pixel-groups or small tiles. >>> >>> Well, not really. The three formats which have non-integer cpp are: >>> DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and >>> DRM_FORMAT_YUV420_10BIT. These formats are only valid with non-linear >>> modifiers (no linear encoding is defined). Mali only supports them >>> with AFBC. >>> >>> The formats themselves have no notion of tiling or grouping - the >>> modifier adds that. I'm not aware of any non-AFBC uses of these >>> formats, so I don't want to "make up" a small-tile layout restriction >>> for them. >> >> >> Ah, I missed that. >> >>> > For very special stuff like afbc you need to validate in the driver >>> > anyway, too complicated. So I have no idea why you bring this up here? >>> >>> Sure, we can just let drivers provide their own format_info's for >>> these, if that's what you prefer. The core format checking code can >>> error out if it ever encounters them. >> >> >> It's format_info we're talking about. What I mean is that you just set all >> these to 0 and let the format_info code ignore it. And then having a >> bespoke drm_format_check_afbc helper function or similar, which checks all >> the layout restrictions of afbc. >> >> I still maintain that bpp and tile_size are equavalent, and we really >> don't need both. Both are defacto a form of numerator/denumerator. If you >> don't like that you have to introduce "fake" tiles for afbc, then we can >> rename tile_size to numerator and tile_h/w to denumerator_h/w. Doesn't >> change one bit of the math. bpp simply hardcodes a denumerator of 8, and I >> don't see why we need that special case. Except if you love to write >> redundant self tests for all the math :-) >> >> So two options that I think are reasonable: >> - one common numerator/denumerator. I don't care how you call that >> bikeshed. > > > Sorry for being dense, but I'm still struggling to get my head around > what you're suggesting. In particular "bpp simply hardcodes a > denumerator of 8" didn't make any sense to me. Could you give concrete > examples for how you think this would look for e.g. > > - DRM_FORMAT_VUY101010. 30-bits per pixel, no tiling. > - DRM_FORMAT_Y0L2. 16-bits per pixel, 2x2 pixel tiles Ok, a few examples: 4 cpp: tile_size = 4, tile_h/w = 1 30 bpp: In cpp that's 30 / 8 = 15 / 4. So would be a tile_size = 15, tile_w = 4, tile_h = 1. If you check the math, this matches exactly all the same addfb values as what you have in your bpp computation (but only if you simplify the quotient). 16 bpp, 2x2 tiles: No real math needed here, tile_size = 2 * 2 * 2 = 8, tile_h/w = 2. > I think we need two things: > - The size, in bits, of a tile Nope, you only need it in bytes, because in the end all buffers must align to bytes. The generic formula is: X bpp: tile_size = X / gcd(X, 8), tile_w = 8 / gcd(X, 8), tile_h = 1. No bits needed anywhere. > - The width and height, in pixels, of a tile (currently implicitly > 1x1) Yeah, but only if you use the cpp thing. We could even throw that out, and entirely replace it with tile_size, with the rule that if tile_h/w = 0, then you assume they're both 1. > Do you disagree? Are you just saying that instead of adding .bpp I > should be replacing .cpp with .bpp wholesale? Hopefully the above explains what I mean, and demonstrates that you can express any bpp in terms of tile_size/tile_w. Because bpp is just a special quotient, with a fixed 8 divisor. -Daniel >> - don't check afbc using format_info, have your own helper that does that >> using custom code. > > > We can do this, no problem. > > Thanks, > -Brian > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel Date: Wed, 12 Sep 2018 20:21:56 +0200 Message-ID: References: <20180823152343.6474-1-brian.starkey@arm.com> <20180823152343.6474-2-brian.starkey@arm.com> <20180831081730.GM21634@phenom.ffwll.local> <20180907124535.GA3461@DESKTOP-E1NTVVP.localdomain> <20180907192626.GA7176@phenom.ffwll.local> <20180910085003.GA36@DESKTOP-E1NTVVP.localdomain> <20180910195325.GC19774@phenom.ffwll.local> <20180912135206.GA21008@DESKTOP-E1NTVVP.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id E67C66E0D1 for ; Wed, 12 Sep 2018 18:21:57 +0000 (UTC) Received: by mail-it0-x244.google.com with SMTP id h20-v6so4372005itf.2 for ; Wed, 12 Sep 2018 11:21:57 -0700 (PDT) In-Reply-To: <20180912135206.GA21008@DESKTOP-E1NTVVP.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Brian Starkey Cc: Dave Airlie , Alexandru-Cosmin Gheorghe , Linux Kernel Mailing List , Tomasz Figa , Sean Paul , dri-devel , Liviu Dudau , Ayan Kumar Halder , "Kristian H . Kristensen" List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBTZXAgMTIsIDIwMTggYXQgMzo1MiBQTSwgQnJpYW4gU3RhcmtleSA8YnJpYW4uc3Rh cmtleUBhcm0uY29tPiB3cm90ZToKPiBPbiBNb24sIFNlcCAxMCwgMjAxOCBhdCAwOTo1MzoyNVBN ICswMjAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+Pgo+PiBPbiBNb24sIFNlcCAxMCwgMjAxOCBh dCAwOTo1MDowM0FNICswMTAwLCBCcmlhbiBTdGFya2V5IHdyb3RlOgo+Pj4KPj4+IEhpLAo+Pj4K Pj4+IE9uIEZyaSwgU2VwIDA3LCAyMDE4IGF0IDA5OjI4OjQ0UE0gKzAyMDAsIERhbmllbCBWZXR0 ZXIgd3JvdGU6Cj4+PiA+IE9uIEZyaSwgU2VwIDA3LCAyMDE4IGF0IDAxOjQ1OjM2UE0gKzAxMDAs IEJyaWFuIFN0YXJrZXkgd3JvdGU6Cj4+PiA+ID4gSGkgRGFuaWVsLAo+Pj4gPiA+Cj4+PiA+ID4g T24gRnJpLCBBdWcgMzEsIDIwMTggYXQgMTA6MTc6MzBBTSArMDIwMCwgRGFuaWVsIFZldHRlciB3 cm90ZToKPj4+ID4gPiA+IE9uIFRodSwgQXVnIDIzLCAyMDE4IGF0IDA0OjIzOjQxUE0gKzAxMDAs IEJyaWFuIFN0YXJrZXkgd3JvdGU6Cj4+PiA+ID4gPiA+IFNvbWUgZm9ybWF0cyBoYXZlIGEgbm9u LWludGVnZXIgbnVtYmVyIG9mIGJ5dGVzIHBlciBwaXhlbCwgd2hpY2gKPj4+ID4gPiA+ID4gY2Fu J3QKPj4+ID4gPiA+ID4gYmUgaGFuZGxlZCB3aXRoIHRoZSBleGlzdGluZyAnY3BwJyBmaWVsZCBp biBkcm1fZm9ybWF0X2luZm8uIFRvCj4+PiA+ID4gPiA+IGhhbmRsZQo+Pj4gPiA+ID4gPiB0aGVz ZSBmb3JtYXRzLCBhZGQgYSAnYnBwJyBmaWVsZCwgd2hpY2ggaXMgb25seSB1c2VkIGlmIGNwcFsw XSA9PQo+Pj4gPiA+ID4gPiAwLgo+Pj4gPiA+ID4gPgo+Pj4gPiA+ID4gPiBUaGlzIHVwZGF0ZXMg YWxsIHRoZSB1c2VycyBvZiBmb3JtYXQtPmNwcCBpbiB0aGUgY29yZSBEUk0gY29kZSwKPj4+ID4g PiA+ID4gY29udmVydGluZyB0aGVtIHRvIHVzZSBhIG5ldyBmdW5jdGlvbiB0byBnZXQgdGhlIGJp dHMtcGVyLXBpeGVsCj4+PiA+ID4gPiA+IGZvciBhbnkKPj4+ID4gPiA+ID4gZm9ybWF0Lgo+Pj4g PiA+ID4gPgo+Pj4gPiA+ID4gPiBJdCdzIGFzc3VtZWQgdGhhdCBkcml2ZXJzIHdpbGwgdXNlIHRo ZSAnYnBwJyBmaWVsZCB3aGVuIHRoZXkgYWRkCj4+PiA+ID4gPiA+IHN1cHBvcnQKPj4+ID4gPiA+ ID4gZm9yIHBpeGVsIGZvcm1hdHMgd2l0aCBub24taW50ZWdlciBieXRlcy1wZXItcGl4ZWwuCj4+ PiA+ID4gPiA+Cj4+PiA+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IEJyaWFuIFN0YXJrZXkgPGJyaWFu LnN0YXJrZXlAYXJtLmNvbT4KPj4+ID4gPiA+Cj4+PiA+ID4gPiBJIGFzc3VtZSB5b3Ugc3RpbGwg cmVxdWlyZSB0aGF0IHN0dWZmIGlzIGV2ZW50dWFsbHkgYWxpZ25lZCB0bwo+Pj4gPiA+ID4gYnl0 ZXM/IEluCj4+PiA+ID4gPiB0aGF0IGNhc2UsIGNhbiB3ZSBzdWJzdW1lIHRoaXMgaW50byB0aGUg dGlsZSB3b3JrIEFsZXggaXMgZG9pbmc/Cj4+PiA+ID4gPiBJdCdzCj4+PiA+ID4gPiBlc3NlbnRp YWxseSBqdXN0IGFub3RoZXIgc3BlY2lhbCBjYXNlIG9mIGhhdmluZyBzdG9yYWdlLXNpemUgdW5p dHMKPj4+ID4gPiA+IG1lYXN1cmVkIGluIGJ5dGVzIHdoaWNoIHNwYW4gbW9yZSB0aGFuIDF4MSBw aXhlbC4gQW5kIEkga2luZGEgZG9uJ3QKPj4+ID4gPiA+IHdhbnQgYQo+Pj4gPiA+ID4gbWV0cmlj IHBpbGUgb2Ygc3BlY2lhbCBjYXNlcyBoZXJlIGluIHRoZSBmb3JtYXQgY29kZSwgYmVjYXVzZSB0 aGF0Cj4+PiA+ID4gPiBqdXN0Cj4+PiA+ID4gPiBtZWFucyBldmVyeSBkcml2ZXIgaGFuZGxlcyBh IGRpZmZlcmVudCBzdWJzZXQsIHdpdGggZGlmZmVyZW50IGJ1Z3MuCj4+PiA+ID4gPiAtRGFuaWVs Cj4+PiA+ID4KPj4+ID4gPiBTb3JyeSBmb3IgdGhlIGRlbGF5LCBiZWVuIHN0cnVnZ2xpbmcgdG8g ZnJlZSBzb21lIGN5Y2xlcyB0byB0aGluawo+Pj4gPiA+IGFib3V0IHRoaXMuCj4+PiA+ID4KPj4+ ID4gPiBJJ20gbm90IHN1cmUgaG93IHRvIHB1bGwgdGhpcyBpbiB3aXRoIHRoZSB0aWxpbmcgc3R1 ZmYuIEluIHRoZSBBRkJDCj4+PiA+ID4gY2FzZSB0aGVuIG91ciBBRkJDIHN1cGVyYmxvY2tzIGFy ZSBhbHdheXMgbmljZSByb3VuZCBudW1iZXJzICgyNTYKPj4+ID4gPiBwaXhlbHMpLCBhbmQgc28g aXQgZG9lcyBlbmQgdXAgYmVpbmcgYSBtdWx0aXBsZSBvZiBieXRlcy4KPj4+ID4gPgo+Pj4gPiA+ IEhvd2V2ZXIsIEFGQkMgc3VwcG9ydHMgZGlmZmVyZW50IHN1cGVyYmxvY2sgc2l6ZXMsIHNvIHBp Y2tpbmcganVzdAo+Pj4gPiA+IG9uZQo+Pj4gPiA+IGRvZXNuJ3QgcmVhbGx5IHdvcmsgb3V0LCBh bmQgcHV0dGluZyBBRkJDIGluIHRoZSBjb3JlIGZvcm1hdCB0YWJsZQo+Pj4gPiA+IHdoaWNoIHJl ZmxlY3RzIEFGQkMgZG9lc24ndCBzZWVtIGdvb2QuCj4+PiA+ID4KPj4+ID4gPiBXZSBjb3VsZCBt YWtlIHNvbWV0aGluZyB1cCAoZS5nLiBjYWxsIHRoZXNlIGZvcm1hdHMgInRpbGVkIiB3aXRoIDJ4 NAo+Pj4gPiA+IHRpbGVzLCB3aGljaCBndWFyYW50ZWVzIGEgbXVsdGlwbGUgb2YgOCksIGJ1dCBp dCB3b3VsZCBiZSBhbgo+Pj4gPiA+IGFyYml0cmFyaWx5LXNlbGVjdGVkIGxpZSwgd2hpY2ggb2Z0 ZW4gc2VlbXMgdG8gc3BlbGwgdHJvdWJsZS4gSWYgd2UKPj4+ID4gPiBkaWQgZG8gdGhhdCwgd291 bGQgeW91IHJlLWRlZmluZSBjcHAgYXMgImJ5dGVzLXBlci10aWxlIj8gT3RoZXJ3aXNlCj4+PiA+ ID4gd2Ugc3RpbGwgbmVlZCB0byBhZGQgYSBuZXcgZmllbGQgYW55d2F5Lgo+Pj4gPiA+Cj4+PiA+ ID4gV2hhdCdzIHRoZSBwaWxlIG9mIHNwZWNpYWwgY2FzZXMgeW91J3JlIHdvcnJpZWQgYWJvdXQ/ IFRoZSBoZWxwZXIKPj4+ID4gPiBJJ3ZlCj4+PiA+ID4gYWRkZWQgaGVyZSBtZWFucyB0aGF0IGRy aXZlcnMgd2hpY2ggbmVlZCB0byBjYXJlIGNhbiB1c2Ugb25lIEFQSSBhbmQKPj4+ID4gPiBub3Qg aW1wbGVtZW50IHRoZWlyIG93biBidWdzLgo+Pj4gPgo+Pj4gPiBJJ20gY29uZnVzZWQgLi4uIHRo ZSBuZXcgYml0cy1wZXItcGl4ZWwgc3R1ZmYgeW91J3JlIGFkZGluZyBoZXJlIGlzIGZvcgo+Pj4g PiB5dXYgZm9ybWF0cywgbm90IGFmYmMuIEknbSBqdXN0IHN1Z2dlc3Rpbmcgd2UgaGF2ZSBvbmx5 IDEgd2F5IG9mCj4+PiA+IGRlc2NyaWJpbmcgc3VjaCBmb3JtYXRzIHRoYXQgbmVlZCBtb3JlIGRl c2NyaXB0aXZlIHBvd2VyIHRoYW4gY3BwLAo+Pj4gPiB3aGV0aGVyCj4+PiA+IHRoZXkgaGF2ZSBz b21lIGtpbmQgb2YgcGl4ZWwtZ3JvdXBzIG9yIHNtYWxsIHRpbGVzLgo+Pj4KPj4+IFdlbGwsIG5v dCByZWFsbHkuIFRoZSB0aHJlZSBmb3JtYXRzIHdoaWNoIGhhdmUgbm9uLWludGVnZXIgY3BwIGFy ZToKPj4+IERSTV9GT1JNQVRfVlVZMTAxMDEwLCBEUk1fRk9STUFUX1lVVjQyMF84QklUIGFuZAo+ Pj4gRFJNX0ZPUk1BVF9ZVVY0MjBfMTBCSVQuIFRoZXNlIGZvcm1hdHMgYXJlIG9ubHkgdmFsaWQg d2l0aCBub24tbGluZWFyCj4+PiBtb2RpZmllcnMgKG5vIGxpbmVhciBlbmNvZGluZyBpcyBkZWZp bmVkKS4gTWFsaSBvbmx5IHN1cHBvcnRzIHRoZW0KPj4+IHdpdGggQUZCQy4KPj4+Cj4+PiBUaGUg Zm9ybWF0cyB0aGVtc2VsdmVzIGhhdmUgbm8gbm90aW9uIG9mIHRpbGluZyBvciBncm91cGluZyAt IHRoZQo+Pj4gbW9kaWZpZXIgYWRkcyB0aGF0LiBJJ20gbm90IGF3YXJlIG9mIGFueSBub24tQUZC QyB1c2VzIG9mIHRoZXNlCj4+PiBmb3JtYXRzLCBzbyBJIGRvbid0IHdhbnQgdG8gIm1ha2UgdXAi IGEgc21hbGwtdGlsZSBsYXlvdXQgcmVzdHJpY3Rpb24KPj4+IGZvciB0aGVtLgo+Pgo+Pgo+PiBB aCwgSSBtaXNzZWQgdGhhdC4KPj4KPj4+ID4gRm9yIHZlcnkgc3BlY2lhbCBzdHVmZiBsaWtlIGFm YmMgeW91IG5lZWQgdG8gdmFsaWRhdGUgaW4gdGhlIGRyaXZlcgo+Pj4gPiBhbnl3YXksIHRvbyBj b21wbGljYXRlZC4gU28gSSBoYXZlIG5vIGlkZWEgd2h5IHlvdSBicmluZyB0aGlzIHVwIGhlcmU/ Cj4+Pgo+Pj4gU3VyZSwgd2UgY2FuIGp1c3QgbGV0IGRyaXZlcnMgcHJvdmlkZSB0aGVpciBvd24g Zm9ybWF0X2luZm8ncyBmb3IKPj4+IHRoZXNlLCBpZiB0aGF0J3Mgd2hhdCB5b3UgcHJlZmVyLiBU aGUgY29yZSBmb3JtYXQgY2hlY2tpbmcgY29kZSBjYW4KPj4+IGVycm9yIG91dCBpZiBpdCBldmVy IGVuY291bnRlcnMgdGhlbS4KPj4KPj4KPj4gSXQncyBmb3JtYXRfaW5mbyB3ZSdyZSB0YWxraW5n IGFib3V0LiBXaGF0IEkgbWVhbiBpcyB0aGF0IHlvdSBqdXN0IHNldCBhbGwKPj4gdGhlc2UgdG8g MCBhbmQgbGV0IHRoZSBmb3JtYXRfaW5mbyBjb2RlIGlnbm9yZSBpdC4gQW5kIHRoZW4gaGF2aW5n IGEKPj4gYmVzcG9rZSBkcm1fZm9ybWF0X2NoZWNrX2FmYmMgaGVscGVyIGZ1bmN0aW9uIG9yIHNp bWlsYXIsIHdoaWNoIGNoZWNrcyBhbGwKPj4gdGhlIGxheW91dCByZXN0cmljdGlvbnMgb2YgYWZi Yy4KPj4KPj4gSSBzdGlsbCBtYWludGFpbiB0aGF0IGJwcCBhbmQgdGlsZV9zaXplIGFyZSBlcXVh dmFsZW50LCBhbmQgd2UgcmVhbGx5Cj4+IGRvbid0IG5lZWQgYm90aC4gQm90aCBhcmUgZGVmYWN0 byBhIGZvcm0gb2YgbnVtZXJhdG9yL2RlbnVtZXJhdG9yLiBJZiB5b3UKPj4gZG9uJ3QgbGlrZSB0 aGF0IHlvdSBoYXZlIHRvIGludHJvZHVjZSAiZmFrZSIgdGlsZXMgZm9yIGFmYmMsIHRoZW4gd2Ug Y2FuCj4+IHJlbmFtZSB0aWxlX3NpemUgdG8gbnVtZXJhdG9yIGFuZCB0aWxlX2gvdyB0byBkZW51 bWVyYXRvcl9oL3cuIERvZXNuJ3QKPj4gY2hhbmdlIG9uZSBiaXQgb2YgdGhlIG1hdGguIGJwcCBz aW1wbHkgaGFyZGNvZGVzIGEgZGVudW1lcmF0b3Igb2YgOCwgYW5kIEkKPj4gZG9uJ3Qgc2VlIHdo eSB3ZSBuZWVkIHRoYXQgc3BlY2lhbCBjYXNlLiBFeGNlcHQgaWYgeW91IGxvdmUgdG8gd3JpdGUK Pj4gcmVkdW5kYW50IHNlbGYgdGVzdHMgZm9yIGFsbCB0aGUgbWF0aCA6LSkKPj4KPj4gU28gdHdv IG9wdGlvbnMgdGhhdCBJIHRoaW5rIGFyZSByZWFzb25hYmxlOgo+PiAtIG9uZSBjb21tb24gbnVt ZXJhdG9yL2RlbnVtZXJhdG9yLiBJIGRvbid0IGNhcmUgaG93IHlvdSBjYWxsIHRoYXQKPj4gIGJp a2VzaGVkLgo+Cj4KPiBTb3JyeSBmb3IgYmVpbmcgZGVuc2UsIGJ1dCBJJ20gc3RpbGwgc3RydWdn bGluZyB0byBnZXQgbXkgaGVhZCBhcm91bmQKPiB3aGF0IHlvdSdyZSBzdWdnZXN0aW5nLiBJbiBw YXJ0aWN1bGFyICJicHAgc2ltcGx5IGhhcmRjb2RlcyBhCj4gZGVudW1lcmF0b3Igb2YgOCIgZGlk bid0IG1ha2UgYW55IHNlbnNlIHRvIG1lLiBDb3VsZCB5b3UgZ2l2ZSBjb25jcmV0ZQo+IGV4YW1w bGVzIGZvciBob3cgeW91IHRoaW5rIHRoaXMgd291bGQgbG9vayBmb3IgZS5nLgo+Cj4gLSBEUk1f Rk9STUFUX1ZVWTEwMTAxMC4gMzAtYml0cyBwZXIgcGl4ZWwsIG5vIHRpbGluZy4KPiAtIERSTV9G T1JNQVRfWTBMMi4gMTYtYml0cyBwZXIgcGl4ZWwsIDJ4MiBwaXhlbCB0aWxlcwoKT2ssIGEgZmV3 IGV4YW1wbGVzOgoKNCBjcHA6IHRpbGVfc2l6ZSA9IDQsIHRpbGVfaC93ID0gMQoKMzAgYnBwOiBJ biBjcHAgdGhhdCdzIDMwIC8gOCA9IDE1IC8gNC4gU28gd291bGQgYmUgYSB0aWxlX3NpemUgPSAx NSwKdGlsZV93ID0gNCwgdGlsZV9oID0gMS4gSWYgeW91IGNoZWNrIHRoZSBtYXRoLCB0aGlzIG1h dGNoZXMgZXhhY3RseQphbGwgdGhlIHNhbWUgYWRkZmIgdmFsdWVzIGFzIHdoYXQgeW91IGhhdmUg aW4geW91ciBicHAgY29tcHV0YXRpb24KKGJ1dCBvbmx5IGlmIHlvdSBzaW1wbGlmeSB0aGUgcXVv dGllbnQpLgoKMTYgYnBwLCAyeDIgdGlsZXM6IE5vIHJlYWwgbWF0aCBuZWVkZWQgaGVyZSwgdGls ZV9zaXplID0gMiAqIDIgKiAyID0KOCwgdGlsZV9oL3cgPSAyLgoKCj4gSSB0aGluayB3ZSBuZWVk IHR3byB0aGluZ3M6Cj4gLSBUaGUgc2l6ZSwgaW4gYml0cywgb2YgYSB0aWxlCgpOb3BlLCB5b3Ug b25seSBuZWVkIGl0IGluIGJ5dGVzLCBiZWNhdXNlIGluIHRoZSBlbmQgYWxsIGJ1ZmZlcnMgbXVz dAphbGlnbiB0byBieXRlcy4gVGhlIGdlbmVyaWMgZm9ybXVsYSBpczoKClggYnBwOiB0aWxlX3Np emUgPSBYIC8gZ2NkKFgsIDgpLCB0aWxlX3cgPSA4IC8gZ2NkKFgsIDgpLCB0aWxlX2ggPSAxLgoK Tm8gYml0cyBuZWVkZWQgYW55d2hlcmUuCgo+IC0gVGhlIHdpZHRoIGFuZCBoZWlnaHQsIGluIHBp eGVscywgb2YgYSB0aWxlIChjdXJyZW50bHkgaW1wbGljaXRseQo+ICAgMXgxKQoKWWVhaCwgYnV0 IG9ubHkgaWYgeW91IHVzZSB0aGUgY3BwIHRoaW5nLiBXZSBjb3VsZCBldmVuIHRocm93IHRoYXQg b3V0LAphbmQgZW50aXJlbHkgcmVwbGFjZSBpdCB3aXRoIHRpbGVfc2l6ZSwgd2l0aCB0aGUgcnVs ZSB0aGF0IGlmIHRpbGVfaC93Cj0gMCwgdGhlbiB5b3UgYXNzdW1lIHRoZXkncmUgYm90aCAxLgoK PiBEbyB5b3UgZGlzYWdyZWU/IEFyZSB5b3UganVzdCBzYXlpbmcgdGhhdCBpbnN0ZWFkIG9mIGFk ZGluZyAuYnBwIEkKPiBzaG91bGQgYmUgcmVwbGFjaW5nIC5jcHAgd2l0aCAuYnBwIHdob2xlc2Fs ZT8KCkhvcGVmdWxseSB0aGUgYWJvdmUgZXhwbGFpbnMgd2hhdCBJIG1lYW4sIGFuZCBkZW1vbnN0 cmF0ZXMgdGhhdCB5b3UKY2FuIGV4cHJlc3MgYW55IGJwcCBpbiB0ZXJtcyBvZiB0aWxlX3NpemUv dGlsZV93LiBCZWNhdXNlIGJwcCBpcyBqdXN0CmEgc3BlY2lhbCBxdW90aWVudCwgd2l0aCBhIGZp eGVkIDggZGl2aXNvci4KLURhbmllbAoKPj4gLSBkb24ndCBjaGVjayBhZmJjIHVzaW5nIGZvcm1h dF9pbmZvLCBoYXZlIHlvdXIgb3duIGhlbHBlciB0aGF0IGRvZXMgdGhhdAo+PiAgdXNpbmcgY3Vz dG9tIGNvZGUuCj4KPgo+IFdlIGNhbiBkbyB0aGlzLCBubyBwcm9ibGVtLgo+Cj4gVGhhbmtzLAo+ IC1Ccmlhbgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKPiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0 b3Aub3JnCj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9k cmktZGV2ZWwKCgoKLS0gCkRhbmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENv cnBvcmF0aW9uCis0MSAoMCkgNzkgMzY1IDU3IDQ4IC0gaHR0cDovL2Jsb2cuZmZ3bGwuY2gKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1h aWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMu ZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==