00:38 anholt: mareko: commented on the MR
00:41 mareko: thanks
12:50 MrCooper: karolherbst: the "rusticl: implement CL 3.1 platform features" commit broke the piglit clSetKernelArg test, expected?
12:51 MrCooper: looks like it given the last commit in the MR
13:05 MrCooper: Venemo: "modifiers don't support mip mapping" would imply some kind of conflict between tiling and mipmaps, which I've never heard of; I suspect what was meant might be that there's currently no general API to create a texture with a modifier and mipmaps
13:07 Venemo: MrCooper: are there any mip mapped formats in drm_fourcc?
13:07 Venemo: I think that modifiers are missing some information for mip maps
13:08 Venemo: but then, I don't know much about that. I trust mareko on this
13:08 MrCooper: "mip-mapped formats" isn't a thing, mip-mapping and formats are orthogonal concepts
13:08 zmike: ^ fact
13:10 MrCooper: (I suppose mip mapping can't work with non-filterable formats, e.g. integer ones)
13:10 MrCooper: that's not related to modifiers / tiling though
13:15 daniels: most APIs which consume formats & modifiers only take format/modifier/width/height/stride/fd/offset as params; if you wanted to throw full mip chains around, you'd need either to pack them all into a single memory region and pass the number of levels + surface stride into whatever API consumes that, or have a two-level API where you import each level separately before combining them into a single resource
13:16 mareko: additional data that comes with modifiers like offsets and strides are not enough to describe mipmapping in theory
13:18 MrCooper: not really seeing the difference to tiling without modifiers
13:24 emersion: i'm not too familiar with mipmaps, it's just a regular image with some additional metadata describing where/how the different versions of the image are stored?
13:24 emersion: but it's still using your regular RGBA pixel arrangement?