From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces Date: Thu, 22 Feb 2018 11:21:34 -0800 Message-ID: <87fu5sakzl.fsf@anholt.net> References: <20171220085151.6327051e@nvidia.com> <20171220124134.0d69513b@nvidia.com> <20180221061446.GA201748@gaspar.pdx.corp.google.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0858380945==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Kristian =?utf-8?Q?H=C3=B8gsberg?= , Alex Deucher Cc: Rob Clark , Chad Versace , dri-devel , Jason Ekstrand , Kristian =?utf-8?Q?H=C3=B8gsberg?= , Ben Skeggs , Miguel Angel Vico , mesa-dev , Lyude Paul , Nicolai =?utf-8?Q?H=C3=A4hnle?= List-Id: dri-devel@lists.freedesktop.org --===============0858380945== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kristian H=C3=B8gsberg writes: > On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher wrot= e: > >> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace > wrote: >> > On Thu 21 Dec 2017, Daniel Vetter wrote: >> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen < > hoegsberg@google.com> wrote: >> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico < > mvicomoya@nvidia.com> wrote: >> >>>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian H=C3=B8gsberg < > hoegsberg@gmail.com> wrote: >> >>>>> I'd like to see concrete examples of actual display controllers >> >>>>> supporting more format layouts than what can be specified with a 64 >> >>>>> bit modifier. >> >>>> >> >>>> The main problem is our tiling and other metadata parameters can't >> >>>> generally fit in a modifier, so we find passing a blob of metadata a >> >>>> more suitable mechanism. >> >>> >> >>> I understand that you may have n knobs with a total of more than a > total of >> >>> 56 bits that configure your tiling/swizzling for color buffers. What > I don't >> >>> buy is that you need all those combinations when passing buffers > around >> >>> between codecs, cameras and display controllers. Even if you're > sharing >> >>> between the same 3D drivers in different processes, I expect just > locking >> >>> down, say, 64 different combinations (you can add more over time) and >> >>> assigning each a modifier would be sufficient. I doubt you'd extract >> >>> meaningful performance gains from going all the way to a blob. >> > >> > I agree with Kristian above. In my opinion, choosing to encode in >> > modifiers a precise description of every possible tiling/compression >> > layout is not technically incorrect, but I believe it misses the point. >> > The intention behind modifiers is not to exhaustively describe all >> > possibilites. >> > >> > I summarized this opinion in VK_EXT_image_drm_format_modifier, >> > where I wrote an "introdution to modifiers" section. Here's an excerpt: >> > >> > One goal of modifiers in the Linux ecosystem is to enumerate for > each >> > vendor a reasonably sized set of tiling formats that are > appropriate for >> > images shared across processes, APIs, and/or devices, where each >> > participating component may possibly be from different vendors. >> > A non-goal is to enumerate all tiling formats supported by all > vendors. >> > Some tiling formats used internally by vendors are inappropriate f= or >> > sharing; no modifiers should be assigned to such tiling formats. > >> Where it gets tricky is how to select that subset? Our tiling mode >> are defined more by the asic specific constraints than the tiling mode >> itself. At a high level we have basically 3 tiling modes (out of 16 >> possible) that would be the minimum we'd want to expose for gfx6-8. >> gfx9 uses a completely new scheme. >> 1. Linear (per asic stride requirements, not usable by many hw blocks) >> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick) >> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible), >> tile split (7 possible), sample split (4 possible), num banks (4 >> possible), bank width (4 possible), bank height (4 possible), macro >> tile aspect (4 possible) all of which are asic config specific) > >> I guess we could do something like: >> AMD_GFX6_LINEAR_ALIGNED_64B >> AMD_GFX6_LINEAR_ALIGNED_256B >> AMD_GFX6_LINEAR_ALIGNED_512B >> AMD_GFX6_1D_THIN_DISPLAY >> AMD_GFX6_1D_THIN_DEPTH >> AMD_GFX6_1D_THIN_ROTATED >> AMD_GFX6_1D_THIN_THIN >> AMD_GFX6_1D_THIN_THICK > > AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_= NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NU= M_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_= NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM= _BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NU= M_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPL= IT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT= _1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPL= IT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_= 1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT= _1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 >> etc. > >> We only probably need 40 bits to encode all of the tiling parameters >> so we could do family, plus tiling encoding that still seems unwieldy >> to deal with from an application perspective. All of the parameters >> affect the alignment requirements. > > We discussed this earlier in the thread, here's what I said: > > Another point here is that the modifier doesn't need to encode all the > thing you have to communicate to the HW. For a given width, height, forma= t, > compression type and maybe a few other high-level parameters, I'm skeptic= al > that the remaining tile parameters aren't just mechanically derivable usi= ng > a fixed table or formula. So instead of thinking of the modifiers as > something you can just memcpy into a state packet, it identifies a family > of configurations - enough information to deterministically derive the fu= ll > exact configuration. The formula may change, for example for different > hardware or if it's determined to not be optimal, and in that case, we can > use a new modifier to represent to new formula. Agreed. For Broadcom's VC5+ stuff, our tiling layout depends on the number of SDRAM banks and bank size, but all users of buffers will know what those are, so I'm not planning on including those in the modifier. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlqPGD8ACgkQtdYpNtH8 nuhNxg//dQqhpNbdNok/oJ/K5mPDzCfDmRyGNJtCSVpGFScJRmpNlm1wxaNPDZYh dHtMji1sOGTD4kw2xy0piRDNvOWJ4MQC+nX/aDO4Wx610nQNxKRf01bKv/9FI6gf YK+4kPGTKOO4c/qTzxbHjBdWPxAJk+SlV4ysfHT3Ei8xm3ODSVjY3zqOTzvne8of UPz9jBCa24oR/lqShzu2awtHebF3bM1anyIJq7ymTDBdlGDwQeiMhXYx9t7NOOvo TXwqh0FoF53j3eRki5it4gt8lJzROP8jjqfh6JlK6SZDjW0xn7i+wbHpNj00iDF0 OmrJbNJN3pqaEH2RiMkxqopN/5iLUIU3Lw8HeAJYKanHTfDRo3qNJDgbc1y9PcGD n79uR0uO9Jm/WTeQiRIrWdgpRg11JhEfl4f9zrMNsigTNpZ9V/LS22ZGPo12iAyy d4+mRplfofCReKmXF1yF4XLfHDkqe5qX11L+zCqdSxxAqjJ5QlzIv4XN8wkSnVSV 0gOMhVmyo4lnvk1JITTK7mWRErYDMB7v0V2tSXEX5qQrzBZMcTic7w0kOyBjtBIQ 5QEe6XatiK3tLYDIuUQqEUpQYUqgGXEMGwYy3LvCu2tRdMuVU2tFpLKsAWjKBkAw iw1fDKQ1bk9rX50ooBi0CXZnIVyL5XrieBjthtVqw6OEvOzLxME= =mZZ5 -----END PGP SIGNATURE----- --=-=-=-- --===============0858380945== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0858380945==--