IRC Logs of #dri-devel on for 2016-08-29

Previous dayChoose dateNext day Show menu

00:29 #dri-devel: < imirkin> hrmph. i filed a bug on the khronos bz about ARB_ES3_compatibility being unclear about whether the ETC2 textures had to be updatable via glTexImage. it seems to have disappeared =/
01:04 #dri-devel: < imirkin> yep - it's gone.
01:04 #dri-devel: < imirkin> gr
01:06 #dri-devel: * airlied wondesr did they lose some of database
01:08 #dri-devel: < imirkin> or they didn't like my question and deleted it
01:08 #dri-devel: <+airlied> that would require someone to read the public bugzilla :P
01:08 #dri-devel: < imirkin> hehe
01:22 #dri-devel: < kisak> imirkin: oh hey ... KHR_texture_compression_astc_ldr is not required for ARB_ES3_2_compatibility
01:23 #dri-devel: < imirkin> kisak: indeed it is not.
01:23 #dri-devel: < imirkin> kisak: neither is advanced blend
01:23 #dri-devel: < kisak> that's mildly amusing that it's done that way
01:24 #dri-devel: < imirkin> i don't write the specs, i just read 'em
01:26 #dri-devel: < fredrikh> i wonder why they require things in the _compatibility extensions that desktop GPU's don't support
01:27 #dri-devel: < imirkin> that's probably why astc was left out
01:27 #dri-devel: < imirkin> no gpu supports advanced blend though
01:28 #dri-devel: < fredrikh> oh never mind, i misread
01:29 #dri-devel: < fredrikh> that one can be emulated in shaders though
01:29 #dri-devel: < imirkin> yep
01:30 #dri-devel: < imirkin> but it's not entirely clear why it exists... just stick the outputs into an image and move on
01:30 #dri-devel: < imirkin> why make an ext that implements *some* weird blend strategies
01:30 #dri-devel: < imirkin> maybe the hope is that some of them will become implemented in hw... dunno
01:32 #dri-devel: <+airlied> isn't it more tilers can do this more efficentyl?
01:32 #dri-devel: < imirkin> maybe.
01:32 #dri-devel: < imirkin> right, in ES you don't have to support images in frag shaders
01:32 #dri-devel: < imirkin> although AEP clamps down on that
01:35 #dri-devel: < fredrikh> imirkin: my theory is that nvidia wrote the shaders to accelerate xrender, and then decided to expose the functionality in a GL extension :)
01:35 #dri-devel: < imirkin> does xrender support those blend modes?
01:36 #dri-devel: < imirkin> i do wonder if glamor should be rewritten with image support
01:36 #dri-devel: < imirkin> (or a new renderer added)
01:36 #dri-devel: < fredrikh> it does
01:39 #dri-devel: < imirkin> airlied: could i convince you do a quick ack of my khr header update?
01:40 #dri-devel: <+airlied> I think it's for SVG rendering mostly, but hard to find decent history
01:41 #dri-devel: <+airlied> imirkin: ack looks good
01:41 #dri-devel: < imirkin> airlied: thanks
02:05 #dri-devel: <+airlied> imirkin: did enhahcned layouts get too messy?
02:06 #dri-devel: < imirkin> airlied: tbh i haven't gotten back to it
02:06 #dri-devel: < imirkin> i was going to do it today
02:07 #dri-devel: < imirkin> but then ES 3.2 seemed like a more appealing task
02:07 #dri-devel: < imirkin> (read: easier)
02:07 #dri-devel: < imirkin> with enhanced layouts, i just need to massage st_glsl_to_tgsi.cpp a bit.... a bit more than i had originally hoped.
02:08 #dri-devel: <+airlied> never a fun task
02:08 #dri-devel: < imirkin> and also my original patch appears to have broken ... something. i guess i'll have to figure out what. but all the tess stuff got broken by it somehow
02:11 #dri-devel: < imirkin> anyways, if you (or someone else) wanted to take it over, be my guest
02:12 #dri-devel: * airlied would have to dig myself out of vulkan first :_P
02:15 #dri-devel: < imirkin> sure
02:19 #dri-devel: * kisak ponders the prospects of radv in the long run
02:21 #dri-devel: < fredrikh> airlied: speaking of vulkan, am i right in guessing that the open source drivers will let you get away with things such as freeing device memory while it's busy?
02:29 #dri-devel: <+airlied> kisak: how long are you running for?
02:30 #dri-devel: <+airlied> fredrikh: if vulkan lets you away with it, we'll gladly let you try :)
02:32 #dri-devel: < fredrikh> airlied: well the spec says that you're supposed to use a fence and wait until the gpu is done reading/writing to it :)
02:33 #dri-devel: <+airlied> fredrikh: the whole point of vulkan is the user can shoot themselves in any part of themselves at any time
02:33 #dri-devel: < fredrikh> airlied: but i'm guessing that the kernel will save the day and not actually release the memory until the gpu is done with it
02:33 #dri-devel: <+airlied> I know the closed drivers are going to start having workarounds for games, and it's going to be a pain
02:34 #dri-devel: <+airlied> fredrikh: in theory yes, but they also have the option of not freeing the memory and just reusing it for something else
02:34 #dri-devel: <+airlied> nothing to stop them allocating backing store for a number of objects and overwriting themselves either
02:34 #dri-devel: < fredrikh> yeah
02:38 #dri-devel: < kisak> there's still basic tracking of which processes are using the memory so things can be cleaned up after the train wreck of modern game engine design, right?
02:39 #dri-devel: <+airlied> that's up to the kernel
02:51 #dri-devel: < DrNick> the kernel certainly isn't going to allow GPU resources to leak between security boundaries
05:05 #dri-devel: < danvet> architt, dim rebuilds drm-intel-nightly every time you push
05:05 #dri-devel: < danvet> that way you can/need to resolve conflicts when they happen
05:05 #dri-devel: < danvet> instead of one poor integration maintainer doing it all
05:51 #dri-devel: < danvet> seanpaul, "[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()" is for you I guess
05:52 #dri-devel: < danvet> I'd do a full revert which includes the backtrace from the patch + reported-by for both Andrey and Matthijs
05:57 #dri-devel: < architt> danvet, hehe, okay
05:59 #dri-devel: < danvet> architt, it should state thate even
05:59 #dri-devel: < danvet> "rebuilding -nightly" or something similar
06:02 #dri-devel: < architt> it says pushing drm-intel-nightly, didn't mention rebuilding anywhere in the logs
06:05 #dri-devel: < danvet> architt, patch for the script?
06:07 #dri-devel: < architt> danvet, sure, once I properly understand what it does :)

Written by Christoph Brill © 2007-2016

Valid XHTML 1.0 Transitional

Available in Android Market