leizhou has quit [Remote host closed the connection]
leizhou has joined #dri-devel
<zmike>
ty
hansg has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
Calandracas has quit [Read error: Connection reset by peer]
Calandracas has joined #dri-devel
kts has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
hansg has joined #dri-devel
coldfeet has joined #dri-devel
simon-perretta-img has joined #dri-devel
ced117_ has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
rgallaispou has left #dri-devel [#dri-devel]
ced117 has joined #dri-devel
hansg has quit [Read error: No route to host]
ced117_ has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<mairacanal>
mripard, tzimmermann, sima, I was about to apply a fix for V3D that it is on both drm-next and drm-misc-next, but the patch failed to apply and I'll need to fix conflicts in order to apply it on drm-misc-next-fixes
<mairacanal>
it is okay to do that?
<tzimmermann>
mairacanal, i'd say it depends on the impact of the fixup
frieder has quit [Remote host closed the connection]
<mairacanal>
the problem is that I based the fix-up patch on drm-misc-next and before identifying this issue, i applied a patchset that changed a couple of lines changed below my fix
<mairacanal>
but it is just a couple of lines
tyalie has quit []
<sima>
mairacanal, if it's just diff context that's different, that's usually easy to handle
tyalie has joined #dri-devel
<sima>
if you need to do actual changes, that's more complicated
<mairacanal>
just diff
<sima>
yeah that should be fine to rebase and just push
<sima>
will be a small conflict when rebuilding drm-tip, but git maybe realize it's the same you already resolved
<mairacanal>
okay, i'll apply to drm-misc-next-fixes (resolving the small conflict)
<zmike>
if you do `meson configure` in your build dir what does it say for glvnd?
<ondracka>
OK, it says auto... than I think its just the User defined options for some reason showing false, but it actually compiles it...
<ondracka>
I'll do a completely clean build
<zmike>
something changed in the glvnd sections of meson/mesa within the past few months which fucked up most of my systems in this area
<zmike>
so you're not alone here
<zmike>
I think you just need to do meson configure -Dglvnd=false again in your build dir
OftenTimeConsuming has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
<ondracka>
OK, I see now in a fresh build fat warning "Option glvnd value false is replaced by disabled" ;-)
aravind has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
OftenTimeConsuming has joined #dri-devel
<ondracka>
zmike: so I think the config is now correct, the glx-create-context-ext-no-config-context test still fails (with different error though), I'll rerun piglit to see for other changes
<zmike>
well just run that test and get me the info I requested so I can work on it while you run the full suite
<zmike>
I just need the xorg backtrace now
<sghuge>
do we have any CTS tests targeting VK_COPY_ACCELERATION_STRUCTURE_MODE_DE/SERIALIZE_KHR copy mode? Trying to understand how does things look like from API persepctive but couldn't find anything or maybe I don't know how to grep it properly :D
warpme has quit []
Jeremy_Rand_Talos has joined #dri-devel
<zmike>
ondracka: what is the error?
gouchi has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<ondracka>
zmike: actually scratch that, after reboot the failing piglit now passes
<zmike>
great
<zmike>
so we're done here
<ondracka>
I'll run a full suite but for now all looks OK
kxkamil has quit []
LeviYun has joined #dri-devel
<mareko>
do you also get random "fatal: Could not read from remote repository." from gitlab?
LeviYun has quit [Ping timeout: 480 seconds]
<agd5f>
mareko, I've been seeing that periodically over the last few days
kxkamil has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
iive has joined #dri-devel
macromorgan_ has quit []
macromorgan has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mripard has quit [Quit: mripard]
alih has quit []
LeviYun has joined #dri-devel
styformdeoon has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
styformdeoon has quit [Ping timeout: 480 seconds]
styformdeoon has joined #dri-devel
Aura has quit []
epoch101 has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
jkrzyszt_ has quit [Ping timeout: 480 seconds]
illwieckz has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
fab has quit [Quit: fab]
gouchi has quit [Remote host closed the connection]
ondracka has quit [Ping timeout: 480 seconds]
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
nerdopolis has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
styformdeoon has quit [Remote host closed the connection]
ondracka has joined #dri-devel
Company has joined #dri-devel
ondracka has quit [Ping timeout: 480 seconds]
melonai has quit []
guludo has quit [Quit: WeeChat 4.3.3]
guludo has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
alih has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
karenthedorf has joined #dri-devel
LeviYun has joined #dri-devel
leizhou has quit [Remote host closed the connection]
f_ has quit [Ping timeout: 480 seconds]
f_ has joined #dri-devel
Calandracas has joined #dri-devel
Calandracas_ has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<dcbaker>
Is the expectation that memory allocated in vulkan common code by vk_*alloc will not be cleaned up in error cases, and just falls through until the vkAllocationCallbacks is cleaned up?
nerdopolis has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
sukuna1 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
sukuna has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
urja has quit [Read error: Connection reset by peer]
urja has joined #dri-devel
illwieckz has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
iive has quit [Quit: They came for me...]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
melonai has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
Company has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<karenthedorf>
I'm not a dri dev, only an application dev, but my assumption is that every allocation is matched with a free, even in the face of VK_ERROR_DEVICE_LOST.
<karenthedorf>
At least if a custom vkAllocationCallbacks is passed in.
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
Company has quit [Quit: Leaving]
pcercuei has quit [Quit: dodo]
<ishitatsuyuki>
yes, there is a CTS test for this too
<karenthedorf>
Not all VkAllocationCallbcks can clean themselves up. e.g. one that just logs the allocation and then forwards it to malloc/aligned_alloc.