ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
shashanks has quit [Ping timeout: 480 seconds]
afanyulionel has joined #dri-devel
afanyulionel2 has quit [Ping timeout: 480 seconds]
karolherbst has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<Company>
so....
<Company>
Vulkan Push Constants - what's the besst equivalent in GL?
<Company>
because the web says "use a buffer" but my profiler says Mesa spends 20% of the time updating the buffer
<Company>
so I'm starting to suspect the web is wrong
<airlied>
push constants are pretty much glUniform equiv
<airlied>
ubos could be used
<Company>
ubos is what I'm using
<Company>
but the glSubBufferData(0 call causes the 20% CPU usage
<airlied>
might need to allocate the buffer different
<Company>
I tried glBufferData() too, that was even slower
<Company>
but I can try just using a bunch of uniforms
<Company>
I could even try one uniform that looks like an array? Does that matter?
<airlied>
did you try glBufferData with different usage?
<Company>
nope
<Company>
I used DYNAMIC_DRAW
<Company>
could try the other ones
<airlied>
STREAM_DRAW might be an option for your use case
<zmike>
yeah should be fast for drivers that implement buffer invalidation
<Company>
it doesn't tc_buffer_unmap() anymore, but it still spends quite some time in tc_improve_map_buffer_flags() => tc_invalidate_buffer() => si_buffer_create()
<Company>
I'll play with using glUniforms instead of UBOs
a-865 has quit [Remote host closed the connection]
a-865 has joined #dri-devel
tutitutututu has joined #dri-devel
afanyulionel has quit [Ping timeout: 480 seconds]
afanyulionel has joined #dri-devel
<tutitutututu>
You do not know how to link stuff? lld has done it for ages morauns, so was kernel mode Linux doing it, kernel lives inside hw protection ring, which is not suid 0 granted, suid 0 is a consequence it's POSIX user system for file accesses, it has nothing to do with hw mpu protection, kernel mode Linux was the first to remove that, later device tree overlays, ebpf granted access to it, you are so stupid, that it's rather obnoxious, ioctls are very
<tutitutututu>
easy to be added to library os, however rings control just needs to be lifted to userspace, it's hardware it does not care who is in charge of controlling the rings, you start to harass with moto crank gangsters and whores like you killed off Gary Kildall, you uneducated fools, and it ends up that I kill all of your harass gangs in a row. Anal indrek on island with their shared hole Laura are bad jokes, this man owes my dad million dollars, he is
<tutitutututu>
not the sharpest or any kind of self managed person, he is a prank like you, terrorist and you know what happens to terrorists, I assume. If you stalk me again, I finish you.
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
tutitutututu was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<soreau>
another mole bites the dust :P
<soreau>
daniels: ping on !25358
CATS has quit [Ping timeout: 480 seconds]
CATS has joined #dri-devel
kts has joined #dri-devel
leo60228 has quit []
leo60228 has joined #dri-devel
aravind has joined #dri-devel
Loinx has joined #dri-devel
<SolarAquarion>
Good evening!
<SolarAquarion>
mesa/src/compiler/clc/meson.build:92:21: ERROR: File /usr//usr/lib/clc/spirv-mesa3d-.spv does not exist.
<SolarAquarion>
this is a fun build error
<SolarAquarion>
why the hell would it be trying to find something in /usr/usr/ there's nothing in /usr/usr/ ever?
<mattst88>
sounds like you've specified --prefix wrong or something like that
<SolarAquarion>
mattst88, it's the basic arch-meson wrapper file
<mattst88>
you'll have to read the code to figure out what's going wrong -- DYNAMIC_LIBCLC_PATH in src/compiler/clc/meson.build
<SolarAquarion>
mattst88, Dynamic_libclc_path is /usr/lib/clc/
<SolarAquarion>
i find it in that file, but it's static, and so it aint finding it
<SolarAquarion>
i wqasn't finding libclc also during non static build
kxkamil2 has quit [Read error: Connection reset by peer]
<soreau>
SolarAquarion: can you explain what problem you're having again? what package are you trying to build and what command are you using to do it?
kxkamil2 has joined #dri-devel
lstrano_ has quit [Read error: Connection reset by peer]
lstrano_ has joined #dri-devel
sima has joined #dri-devel
<SolarAquarion>
soreau, i fixed the issue that i was having. it's because i changed some stuff which caused everything to fail
<soreau>
glag you got it sorted
<soreau>
glad*
itoral has joined #dri-devel
Duke`` has joined #dri-devel
<SolarAquarion>
[1344/3593] Generating src/intel/vulkan/grl/gfx125_bvh_build_leaf_primref_to_procedurals.h with a custom command (wrapped by meson to set env)
<SolarAquarion>
(file=input,line=0,column=0,index=0): Type mismatch on symbol "store_uint4_L1WB_L3WB" between imported variable/function %77 and exported variable/function %9718.
<SolarAquarion>
[1345/3593] Generating src/intel/vulkan/grl/gfx125_bvh_build_leaf_primref_to_quads.h with a custom command (wrapped by meson to set env)
<SolarAquarion>
(file=input,line=0,column=0,index=0): Type mismatch on symbol "store_uint4_L1WB_L3WB" between imported variable/function %77 and exported variable/function %9718.
<SolarAquarion>
[1346/3593] Generating src/intel/vulkan/grl/gfx125_bvh_build_leaf_create_HW_instance_nodes.h with a custom command (wrapped by meson to set env)
<airlied>
Kayden, dj-death ^ not sure who else to ping :-P
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
tzimmermann has joined #dri-devel
Venemo has joined #dri-devel
pochu has joined #dri-devel
glehmann has joined #dri-devel
pcercuei has joined #dri-devel
<dj-death>
airlied: nice, thanks for that
tursulin has joined #dri-devel
pekkari has joined #dri-devel
mwalle has joined #dri-devel
junaid has joined #dri-devel
neniagh has quit []
neniagh has joined #dri-devel
neniagh has quit []
neniagh has joined #dri-devel
a-865 has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
mvlad has joined #dri-devel
sarahwalker has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
kts has joined #dri-devel
lynxeye has joined #dri-devel
jkrzyszt_ has joined #dri-devel
rasterman has joined #dri-devel
apinheiro has joined #dri-devel
neniagh_ has joined #dri-devel
neniagh has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
neniagh has joined #dri-devel
neniagh_ has quit [Ping timeout: 480 seconds]
cmichael has joined #dri-devel
Haaninjo has joined #dri-devel
itoral has quit [Quit: Leaving]
donaldrobson has joined #dri-devel
tyalie has quit [Quit: Ping timeout (120 seconds)]
bmodem has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: mhhh.. I found the reason why llvmpipe has bad CPU utilization... the bigger the block is, the more likely it becomes, that llvmpipe starves...
<karolherbst>
not sure if that's fixable in a sane way
<karolherbst>
but maybe llvmpipe could decouple subgroups within blocks, and just keep enqueuing "subgroups" from other blocks if one finishes or something? not sure if that's feasible
Danct12 has quit [Remote host closed the connection]
sarahwalker has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
hansg has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jdavies has joined #dri-devel
jdavies is now known as Guest2131
<karolherbst>
gfxstrand: mind if we land the three nir patches from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24764 ? Apparently users are running into this issue and it helps with kernel compilation speeds. We should keep the rusticl patch for when copy_deref gets fixed as well.
Guest2131 has quit [Ping timeout: 480 seconds]
pekkari has joined #dri-devel
kts has joined #dri-devel
yyds has joined #dri-devel
heat has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: also.. I have a CL app which is like 30x faster with pocl than llvmpipe :')
<karolherbst>
and it's just running kernels
<karolherbst>
but it's also doing crypto inside the kernel, so maybe pocl ends up using crypto extensions
kts has quit [Quit: Konversation terminated!]
<karolherbst>
but maybe the way we optimize things is also pretty terrible, and maybe the function stuff we are doing now is slowing things a lot
kts has joined #dri-devel
Company has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
pekkari has quit [Quit: Konversation terminated!]
apinheiro has quit [Quit: Leaving]
ficoPRO10 has joined #dri-devel
donaldrobson has joined #dri-devel
junaid has quit [Remote host closed the connection]
aradhya7 has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
aravind has quit [Remote host closed the connection]
shankaru has quit [Remote host closed the connection]
fdu_ has quit [Remote host closed the connection]
fdu has joined #dri-devel
aravind has joined #dri-devel
shankaru has joined #dri-devel
junaid has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
pzanoni has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
greaser|q has joined #dri-devel
junaid has quit [Remote host closed the connection]
pekkari has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
pekkari has quit []
pekkari has joined #dri-devel
xroumegue has joined #dri-devel
zf has quit [Remote host closed the connection]
pq has quit [Ping timeout: 480 seconds]
zf has joined #dri-devel
kzd has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
alanc has quit [Remote host closed the connection]
mszyprow has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
RSpliet has joined #dri-devel
pq has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
<Company>
so, I did some sysprof on my renderer, and one thing where a bunch of time is spent is a function that essentially memcpy()s stuff into the vertex buffer
<Company>
but that function takes <1% on Vulkan and >10% on GL
<Company>
I copy into a buffer mapped with glMapBuffer(), did I screw things up somehow?
macromorgan_ has joined #dri-devel
Duke`` has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
pekkari has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
<Company>
huh fun, on Intel they're both <1%, this is only AMD
<HdkR>
Are you using glBufferStorage to set the `GL_CLIENT_STORAGE_BIT`?
<HdkR>
Smells like you're accessing vram across PCIe
<Company>
so far I'm just creating a GL_ARRAY_BUFFER and mapping it for writing
<Company>
I played with WRITE_ONLY and READ_WRITE and STATIC_DRAW and DYNAMIC_DRAW but that didn't seem to do anything - though I only looked at framerate and didn't run a full profile
pochu has quit [Ping timeout: 480 seconds]
<HdkR>
Indeed, and it's probably ending up in VRAM. So you're writing a bunch data across the PCIe bus which is slow as snot
<Company>
yeah, that's not supposed to happen
<HdkR>
That's what glBufferStorage is for. Giving the driver more context about what you're wanting to do
<Company>
but glBufferStorage is GL 4.4+ only
<HdkR>
Also glMapBufferRange
<Company>
am I supposed to use CPU memory and glBufferData() otherwise?
<HdkR>
Pretty much
<HdkR>
glBufferData or glBufferSubData depending
<HdkR>
glbufferData will have the driver orphan buffers and do shadow copies of your data, glBufferSubData will theoretically do magic sub-range tracking and updating but mileage may vary :P
<Company>
MapBufferRange looks good
<Company>
I mainly care about GLES 3 and Mesa/nvidia GL (which is usually GL4)
pekkari has quit [Quit: Konversation terminated!]
<Company>
though the oldest junk people seem to use with Gnome seems to be around GL 3 - we've had a few bugs when people's GPUs didn't do samplers
<HdkR>
without `GL_CLIENT_STORAGE_BIT` you're likely still going to shoot yourself in the foot
<HdkR>
But luckily AMD things also usually support GL 4
<karolherbst>
glBufferStorage can be used with an extension almost everybody provides though
<karolherbst>
even gl3 implementations
<karolherbst>
we even had it in the mesa 10 days :D
<karolherbst>
anyway, any competent GL driver has GL_ARB_buffer_storage
<HdkR>
It's even in GLES land with GL_EXT variant which is nice
<mareko>
GL2 has it too
<karolherbst>
I'd consider any implementation not providing it as a broken one
<karolherbst>
:P
<Company>
I shall be using that then and fallback
<karolherbst>
yeah, it makes your life easier
<mareko>
I think virgl can't do ARB_buffer_storage
<mareko>
and svga
<mareko>
that's likely it
<karolherbst>
mhhh.. yeah.. I guess any VM driver might have issues implementing it properly
<karolherbst>
though it should be possible in theory
<MrCooper>
Company: if you draw only once using the vertex data you write, should probably use GL_STREAM_DRAW
<Company>
the other option is going to malloc() + glBufferData() when unmapping
<Company>
MrCooper: I'm reusing the buffer for a later frame
<Company>
but it's unclear to me how people interpret those STREAM vs DYNAMIC flags
<karolherbst>
a use case where I used buffer storage was where I've updated the buffer significantly more often than used on the GPU (multiple 100-thousend times a frame) but on the GPU side it didn't matter which immediate state was visible
<Company>
and how they are meant to map to coherent vs cached vs whatever flags in Vulkan
<MrCooper>
then does the upload time really matter? A buffer in VRAM might be faster for the draws
<Company>
I don't know - but currently I get 4x the framerate with my Vulkan code than with my GL code
<Company>
and I'm trying to figure out why
kts has joined #dri-devel
<MrCooper>
seems unlikely that 10% CPU usage alone could explain 1/4 frame rate
<soreau>
Company: tried zink for kicks?
<Company>
MrCooper: I have more than 1 suspicion of slowdowns - but this here is one thing
<Company>
and when the framerate goes up here I can go look at the next thing
jkrzyszt_ has quit [Remote host closed the connection]
<Company>
fastest method seems to be malloc() + glBufferSubData()
<Company>
and ignoring all the fancy glMapBufferRange() stuff
<zmike>
unsurprising
<Company>
I was assuming that's leading to an extra memcpy()
<zmike>
it is, but if you can't set the memory domain for your buffer then that's still faster
<Company>
how does that just work in Vulkan but GL can't make it work?
<zmike>
because memory allocation in vulkan is explicit by design
<Company>
ah, you mean because GL has to care about syncing everything all the time and that makes things hard to get right
<zmike>
no I mean in GL you're probably trying to write to buffers that use memory not optimal for cpu writes but in VK if you do that it's because you allocated your buffer wrong
<Company>
I was assuming that the fancy glBufferStorage() and glMapBufferRange() flags made the memory optimal
flom_84 has joined #dri-devel
<Company>
that's why I tried avoiding the glBufferSubData() in the first place
<zmike>
I haven't read the backlog
gouchi has joined #dri-devel
<Company>
I'm abstracting the GTK Vulkan renderer to gain a GL backend
<Company>
so I'm basically trying to find GL calls that match the Vulkan stuff I do as well as possible
kts has quit [Quit: Konversation terminated!]
<Company>
and after I did that, I'm getting 600fps on GL and 2500fps on Vulkan
<Company>
and now I'm investigating
flom84 has quit [Ping timeout: 480 seconds]
<Company>
yesterday I was looking at UBOs as push constant replacement being slow
<Company>
today was buffers being slow
jeeeun841351 has joined #dri-devel
krumelmonster has joined #dri-devel
<krumelmonster>
Hi, I get a segmentation fault within mesa, called from imgui (called from my lovely software I want to open source soon) and I've been told to report it to the mesa project however I'm not certain this is a mesa issue and I have no idea how I would isolate the issue from my codebase https://github.com/ocornut/imgui/issues/6896
donaldrobson has quit [Ping timeout: 480 seconds]
<anholt>
have you run under valgrind? also, make sure you have a debugoptimized or debug build of mesa, since you seem to be using a personal build but don't have debug symbols.
<anholt>
crocus_resource_create_for_buffer doesn't look like something that should crash on misuse of gl api
<krumelmonster>
This is archs 23.2.1-1 with debug symbols from debugd -- but actually I will install archs mesa-debug package now so I can use my IDEs debugger from here on. I'm not running under valgrind or any of the such
flom_84 has quit [Remote host closed the connection]
<krumelmonster>
Do you think I should try to make the issue reproducible by trying to dissecting the imgui draw list?
<krumelmonster>
Should I already open an issue in the mesa tracker with only the litte information I have so far?
<vsyrjala>
seems to be the only unchecked crocus_alloc_resource(). so calloc() failed somehow?
<tnt>
krumelmonster: does gdb tell you `res` is NULL ?
sima has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
<krumelmonster>
sorry tnt I moved to bare gdb so I could profit from debugd. I'm in frame 0 but `print res` teslls me No symbol "res" in current context.
<tnt>
You can try to disassemble around the crash to see exactly which opcode failed (to make sure the line estimate from gdb is accurate) and print the register values.
<krumelmonster>
Is there no way I can get to see the locals in gdb like I usually do? info locals says "No locals." for all of the mesa part of this
<krumelmonster>
If neccessary I could try a different build of mesa, this crash typically happens if I just wait
<tnt>
Not sure how arch debug thing works and if it's supposed to include all locals info.
<tnt>
But for sure you can build mesa locally as debug build and use that.
<krumelmonster>
It does usually. It compile with debug symbols, then strips them and ships them separately. I've never seen this not work like this before
kts has joined #dri-devel
mocoo has quit [Ping timeout: 480 seconds]
<krumelmonster>
I assume that debug symbols are enabled by default
<airlied>
optimisatioms will screw up debug even with symbols
<krumelmonster>
should I pass any flags to meson for a particularly debugable build?
Haaninjo has joined #dri-devel
<airlied>
buildtype debug
<krumelmonster>
This was the default apparently as ctrl+c, `meson --buildtype debug ..` then `ninja` didn't start it over
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<krumelmonster>
While waiting for this, back in gdb I can see that the segfault is caused by movl $0x0,0xbc(%r12) where %r12 is a null-pointer if I'm doing this correctly. At least print $r12 says $7 = 0
mszyprow has joined #dri-devel
<krumelmonster>
So that makes a lot of sense with ISL_TILING_LINEAR being 0
<vsyrjala>
there is some special meson command if you want to change any build knobs after the fact. i never remember it so i just rm -rf the build directory instead
<pendingchaos>
"meson configure"
antoniospg has joined #dri-devel
<tnt>
But the only way that pointer would be null would be if calloc returned NULL
<airlied>
sounds like you are using all the ram
<airlied>
or possible all the vm space
<karolherbst>
is this 32 bit by any chance?
<krumelmonster>
no
<krumelmonster>
and free says 2.3Gi available. But maybe it's my application that has the memory leak. I'm currently running it with the fresh mesa build in hopes for it to crash soon :)
<karolherbst>
well.. the thing is, allocation don't fail just because you are out of RAM
<karolherbst>
unless you configure your system in such a way
<karolherbst>
and running out of VM would be kinda unlikely, but still possible
<krumelmonster>
It would be very odd for the malloc to fail and really if res was null it would be more likely to segfault for 657, the line just before
<karolherbst>
with optimizations everything is possible
<karolherbst>
could be reordered
<airlied>
just add an assert and see
<karolherbst>
could also be something entirely else
<karolherbst>
*different
mocoo has joined #dri-devel
<krumelmonster>
I just hope it crashes soon and that my new build has "better" debug symbols
mvlad has quit [Remote host closed the connection]
gio has quit [Ping timeout: 480 seconds]
gio has joined #dri-devel
<krumelmonster>
It doesn't seem to be willing to crash with my own build. Is there anything else I could do to write a useful report in the mesa gitlab?
crabbedhaloablut has quit []
heat has quit [Ping timeout: 480 seconds]
<psykose>
did you build 23.2.1 with the same config as arch or just master?
<psykose>
regardless to make sure it's almost the same thing you could use the same args as that and same tag
<krumelmonster>
I built master but *now it crashed
simon-perretta-img_ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
<krumelmonster>
`info locals` says `res = 0x0`
simon-perretta-img__ has joined #dri-devel
<psykose>
means indeed calloc returned a null
<krumelmonster>
Sadly I missed out on the "meson configure" so the parameters to crocus_alloc_resource are all optimized out... Am I wasting your time?
ngcortes has joined #dri-devel
<HdkR>
Sounds like if you just enable swap then you'll stop running out of memory
<psykose>
what does `sysctl vm.overcommit_memory` return for you
<krumelmonster>
vm.overcommit_memory = 0
<psykose>
okie, normal
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
<psykose>
hm
<psykose>
not exactly sure then
<psykose>
are you able to view the memory usage of the system during the period you ~run the way to crash the thing and seeing if magically you actually do run out of 'available' right before it happens?
<krumelmonster>
not for this past run
<krumelmonster>
I still have to wait 20 minutes for my actual mesa debug build to finish so that's plenty of time to set up some monitoring
<psykose>
something also worth a try is doing vm.overcommit_memory=1 just to see if it behaves different
<psykose>
(note that =0 is also "overcommit enabled", the heuristic is just different)
<psykose>
sadly i'm not familiar if there are other reasons calloc would give you a null, in glibc's allocator (or whatever else), it's a bit more complicated than just 'does computer have memory' etc..
<psykose>
hm
<psykose>
you might also have ran out of `sysctl vm.max_map_count` perhaps, i think on exhaustion that also fails
<karolherbst>
there is also this thing to check for malloc corruptions
<krumelmonster>
May this be a hardware issue? sublime text and firefox have been crashing recently and from what I'm doing with this laptop those might be the two application shoveling most memory
<psykose>
it could be
<krumelmonster>
I'll memtest64 tonight
<karolherbst>
well.. unlikely though
<karolherbst>
why would glibc decide to not allocate memory out of the sudden
<karolherbst>
nah.. 99% of the cases where one thinks it's a hardware issue, it's not :P
<karolherbst>
you can assume hardware issues don't exist unless you have solid proof
<karolherbst>
krumelmonster: what's errno right after the failing calloc call?
<krumelmonster>
I made sure to hand out the same type of laptop I have around friends and there has been a memory defect before as was proven by memtest64. Don't remember how it showed 'though
<karolherbst>
it apparently indicates why it fails
<karolherbst>
not sure if that's part of the posix standard though
<karolherbst>
ahh it is
<karolherbst>
`The setting of errno and the [ENOMEM] error condition are mandatory if an insufficient memory condition occurs.`
rasterman has quit [Quit: Gettin' stinky!]
<psykose>
would be interesting if it's not set
<krumelmonster>
karolherbst I guess I'll have to modify crocus_alloc_resource and then hit the issue again in order to retrieve the errno, right?
<karolherbst>
nah, should be fine
<karolherbst>
just run with gdb and if you hit the error do "p errno"
<krumelmonster>
12
<psykose>
that's enomem
<krumelmonster>
well that's awkward
<karolherbst>
quite so
<karolherbst>
I guess memory consumption and everything is in order?
<karolherbst>
might also be some random cgroup stuff or something
<psykose>
it still doesn't really mean anything that we weren't already guessing
<psykose>
many things that can cause that..
JohnnyonFlame has joined #dri-devel
<karolherbst>
krumelmonster: do "p calloc(8)"
<karolherbst>
ehh wait
<karolherbst>
"p calloc(8, 1)"
<karolherbst>
or rather 1, 8
<karolherbst>
whatever
<krumelmonster>
$3 = (void *) 0x5555562e3bb0
<karolherbst>
mhh
<psykose>
do 1, 256
<krumelmonster>
(gdb) p calloc(8, 1) $3 = (void *) 0x5555562e3bb0 (gdb) p calloc(1, 8) $4 = (void *) 0x55555605e530
<krumelmonster>
(gdb) p calloc(1, 256) $5 = (void *) 0x555556e84120
<tnt>
or calloc worked and something overwrote the result with null ?
<karolherbst>
the best feature of gdb is, that you can throw random C expression at it
<karolherbst>
nah, there is no code for it
<karolherbst>
unless it's a weirdo OOB write
<psykose>
if calloc worked and the result was overwritten errno would probably not be 12
<karolherbst>
but yeah.. you could also do "break crocus_alloc_resource" then "p crocus_alloc_resource(pscreen, templ)" and single step through crocus_alloc_resource
<psykose>
could u just print the sizeof by itself so it's clear how big it is for fun
<karolherbst>
this is what they call remote gdb debugging, aren't they?
<psykose>
:D
<krumelmonster>
(gdb) p sizeof(struct crocus_resource) $7 = 520
<psykose>
thic
<krumelmonster>
:D
<psykose>
so 256 is small enough but 520 is too big
<psykose>
and, it does not just get more mappings
<psykose>
i wonder if you can step into expr?
<karolherbst>
you can
<psykose>
like, step into a `calloc(1, 520)` from it
<karolherbst>
just have to set a breakpoint first
<psykose>
and see why it gives you a null
<karolherbst>
_and_ have debug symbols for glibc :)
<psykose>
aye
<tnt>
Can you check the current process mappings ?
<karolherbst>
ahh good idea
<krumelmonster>
By the way I ran the software again but with the debug build and I closed some big browser windows so system RAM should be out of question.
<HdkR>
`cat /proc/<pidof app>/maps | wc -l` Might have hit the mapping max :)
<karolherbst>
"info maps" or was it "info mem"?
<karolherbst>
something something
mszyprow has quit [Ping timeout: 480 seconds]
<tnt>
info proc mappings
<karolherbst>
ahh
<karolherbst>
krumelmonster: mhhhh...
<karolherbst>
okay...
<karolherbst>
there is this thing
<krumelmonster>
oh ah wow hm
<psykose>
krumelmonster: what's info proc mappings say
<karolherbst>
krumelmonster: "p malloc_trim(0)"
<krumelmonster>
there's a gazillion of `0x7fffd40f3000 0x7fffd40f4000 0x1000 0x106404000 rw-s anon_inode:i915.gem`
<krumelmonster>
in info proc mappings
<psykose>
paste it somewhere
<karolherbst>
after the trim, do the calloc resource thing again
<psykose>
get the number first
<karolherbst>
ahh yeah
<krumelmonster>
it's so many I'll have to figure how to even get to the start of the list... Give me a sec
<karolherbst>
yeah. pastebin the mappings first
<psykose>
and see if it's at 65536 :p
simon-perretta-img_ has joined #dri-devel
<karolherbst>
ohhhhh
<karolherbst>
uhm
<karolherbst>
wasn't there a limit for this kinda stuff?
<psykose>
it's the default for max_map_count which would explain why it can't get more
<psykose>
yes, sysctl vm.max_map_count
<karolherbst>
it's 65530 here
<krumelmonster>
My alacritty scrollback buffer is big but it's not big enough for this
<karolherbst>
but yeah
<karolherbst>
yeah...
<psykose>
fedora these days was looking to default it to infinite and have cgroups instead
<karolherbst>
ahh
<karolherbst>
fair enough
<karolherbst>
but yeah.. having too many mappings would explain it
<psykose>
i've had to debug a lot of "OOM" issues that had 100's of gbs free
<karolherbst>
pain
simon-perretta-img has joined #dri-devel
<tnt>
So now question is where do they come from :)
<karolherbst>
maybe tons of GL contexts created?
<karolherbst>
maybe opengl was dlopened 1000 times?
<karolherbst>
maybe it's just doing a looot of small allocations?
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe the app causes GPU resources to not being fred?
<karolherbst>
something along those lines probably
<psykose>
krumelmonster: set logging file xxx.log
<psykose>
then type it
<psykose>
should output to a file
<psykose>
ah also needs set logging on i think
<krumelmonster>
I think it's too big for my paste service, just a sec
<psykose>
idk anything about that personally but it doesn't smell like it's for this
<krumelmonster>
ok.
<psykose>
you can try, if that codepath builds, to just make it #if 1 and see if it changes something, but eh
ngcortes has quit [Ping timeout: 480 seconds]
<krumelmonster>
The reason I'm investigating it is that I want to open source this project this week. Not that's it's really usable feature-wise but I thought I'd tackle the crashes first. Therefore hiding it is not so much of interest :)
<psykose>
makes sense
<karolherbst>
krumelmonster: maybe there is a bug in your application and you end up doing weirdo things to GL
<psykose>
always possible
<krumelmonster>
Absolutely possible, I have no idea what I'm doing karolherbst
<psykose>
also for future self reference, the 4 ways i was thinking of is cgroup limit, rlimit(lol), max_map_count, and vm.overcommit_memory=2 (actual checked overcommit)
<krumelmonster>
Then again I'm pretty sure I don't create any resources whatsoever when the application is just running like when I wait for this issue
<psykose>
seems to almost always be 3) tho
<psykose>
and 'actual' "i ran out of memory" moments is less "enomem" and more "oom killer gave you a bad day and nuked your unsaved libreoffice"
<krumelmonster>
yes I'd always get the latter
<tnt>
krumelmonster: you can monitor the number of mappings when you're application is running and see if it's a slow leak or a lot at once or ...
<krumelmonster>
Say my application did have a leak of OpenGL resources, could I see this somehow?
<psykose>
valgrind might know? idk if you tried it
<psykose>
it's usually quite good at finding memory issues, especially leaks
<psykose>
there's sanitizers too, asan+lsan is similar for that
<krumelmonster>
I haven't. I thought we where considering a leak of OpenGL resources as in GLcreate something in the mainloop and never delete it or the such
<psykose>
worth a try
<krumelmonster>
By the way: Here's a backtrace where it crashed somewhere else most definitely for the same reason http://ix.io/4Ibe
<psykose>
if it's for the same reason then it's the same reason
<anholt>
valgrind's massif is more likely to help than sanitizers.
<anholt>
but probably better would be porting over the iris_dump_bo_list under INTEL_DEBUG(DEBUG_SUBMIT) and using that to figure out what BOs are being allocated, which may be a hint.
<anholt>
gallium's refcnt leaking stuff might help, but it's a pain to get stood up so I wouldn't start that way, just dump the BOs in use at submit time and try to infer things from their names
<Lynne>
is there an equivalent of #dri-devel, but for those working on future vulkan extensions
<Lynne>
I'd like to both complain and praise a proposed extension
<krumelmonster>
Thank you for all the advices. I'll try to figure out how to read ms_print/massif output. Here's a sample (I didn't wait for the crash) http://ix.io/4Ibj
<krumelmonster>
well actually the ascii art in the beginning says it all probably^^
<krumelmonster>
Albeit all the timewasting I hope you can be happy about having teached me many things. I might have been able to find this myself but rather by taking apart my code until it's fine than with a structured usage of gdb and valgrind so thank you for showing me how it's done :)
ngcortes has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
mocoo has left #dri-devel [Bye!]
cyrozap has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
mmind00 has quit [Ping timeout: 480 seconds]
leo60228 has quit []
mmind00 has joined #dri-devel
leo60228 has joined #dri-devel
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<anholt>
lina: have you done an updated git tree of intel gfx prms?
YuGiOhJCJ has joined #dri-devel
tales-aparecida has joined #dri-devel
pushqrdx[m] has quit [Ping timeout: 480 seconds]
msizanoen[m] has quit [Ping timeout: 480 seconds]
nielsdg has quit [Ping timeout: 480 seconds]
sigmoidfunc[m] has quit [Ping timeout: 480 seconds]
tleydxdy has quit [Ping timeout: 480 seconds]
reactormonk[m] has quit [Ping timeout: 480 seconds]
nyorain[m] has quit [Ping timeout: 480 seconds]
kunal_10185[m] has quit [Ping timeout: 480 seconds]
gdevi has quit [Ping timeout: 480 seconds]
kunal10710[m] has quit [Ping timeout: 480 seconds]
bylaws has quit [Ping timeout: 480 seconds]
talcohen[m] has quit [Ping timeout: 480 seconds]
yshui` has quit [Ping timeout: 481 seconds]
nicofee[m] has quit [Ping timeout: 481 seconds]
doraskayo has quit [Ping timeout: 480 seconds]
q4a has quit [Ping timeout: 480 seconds]
kelbaz[m] has quit [Ping timeout: 480 seconds]
dcbaker has quit [Ping timeout: 480 seconds]
halfline[m] has quit [Ping timeout: 480 seconds]
moben[m] has quit [Ping timeout: 480 seconds]
Anson[m] has quit [Ping timeout: 480 seconds]
robertmader[m] has quit [Ping timeout: 480 seconds]
pankart[m] has quit [Ping timeout: 480 seconds]
vdavid003[m] has quit [Ping timeout: 480 seconds]
MayeulC has quit [Ping timeout: 480 seconds]
pp123[m] has quit [Ping timeout: 480 seconds]
daniliberman[m] has quit [Ping timeout: 480 seconds]
Sofi[m] has quit [Ping timeout: 480 seconds]
Newbyte has quit [Ping timeout: 480 seconds]
AlaaEmad[m] has quit [Ping timeout: 480 seconds]
BilalElmoussaoui[m] has quit [Ping timeout: 484 seconds]
ids1024[m] has quit [Ping timeout: 484 seconds]
EricCurtin[m] has quit [Ping timeout: 484 seconds]
tomeu has quit [Ping timeout: 484 seconds]
Targetball[m] has quit [Ping timeout: 484 seconds]
jenatali has quit [Ping timeout: 480 seconds]
dabrain34[m]1 has quit [Ping timeout: 480 seconds]
naheemsays[m] has quit [Ping timeout: 484 seconds]
Vin[m] has quit [Ping timeout: 480 seconds]
sergi1 has quit [Ping timeout: 480 seconds]
AlexisHernndezGuzmn[m] has quit [Ping timeout: 480 seconds]
bubblethink[m] has quit [Ping timeout: 480 seconds]
treeq[m] has quit [Ping timeout: 480 seconds]
Mershl[m] has quit [Ping timeout: 480 seconds]
enick_185 has quit [Ping timeout: 480 seconds]
ttayar[m] has quit [Ping timeout: 480 seconds]
T_UNIX has quit [Ping timeout: 485 seconds]
tomba has quit [Ping timeout: 480 seconds]
undvasistas[m] has quit [Ping timeout: 485 seconds]
ella-0[m] has quit [Ping timeout: 485 seconds]
swick[m] has quit [Ping timeout: 480 seconds]
YHNdnzj[moz] has quit [Ping timeout: 480 seconds]
DemiMarie has quit [Ping timeout: 480 seconds]
enick_991 has quit [Ping timeout: 480 seconds]
cwfitzgerald[m] has quit [Ping timeout: 480 seconds]
onox[m] has quit [Ping timeout: 480 seconds]
jtatz[m] has quit [Ping timeout: 480 seconds]
devarsht[m] has quit [Ping timeout: 480 seconds]
hch12907 has quit [Ping timeout: 480 seconds]
vidal72[m] has quit [Ping timeout: 480 seconds]
xerpi[m] has quit [Ping timeout: 480 seconds]
ajhalaney[m] has quit [Ping timeout: 480 seconds]
Quinten[m] has quit [Ping timeout: 480 seconds]
x512[m] has quit [Ping timeout: 480 seconds]
koike has quit [Ping timeout: 480 seconds]
cmeissl[m] has quit [Ping timeout: 480 seconds]
Vanfanel has quit [Ping timeout: 480 seconds]
JosExpsito[m] has quit [Ping timeout: 480 seconds]
YaLTeR[m] has quit [Ping timeout: 480 seconds]
viciouss[m] has quit [Ping timeout: 480 seconds]
shoffmeister[m] has quit [Ping timeout: 480 seconds]
isinyaaa[m] has quit [Ping timeout: 480 seconds]
aura[m] has quit [Ping timeout: 480 seconds]
znullptr[m] has quit [Ping timeout: 480 seconds]
FloGrauper[m] has quit [Ping timeout: 480 seconds]
K0bin[m] has quit [Ping timeout: 480 seconds]
ram15[m] has quit [Ping timeout: 480 seconds]
siddh has quit [Ping timeout: 480 seconds]
Hazematman has quit [Ping timeout: 480 seconds]
kos_tom has quit [Ping timeout: 480 seconds]
tak2hu[m] has quit [Ping timeout: 480 seconds]
nick1343[m] has quit [Ping timeout: 480 seconds]
zzoon_OOO_till_03_Oct[m] has quit [Ping timeout: 480 seconds]
exp80[m] has quit [Ping timeout: 480 seconds]
masush5[m] has quit [Ping timeout: 480 seconds]
go4godvin has quit [Ping timeout: 480 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
heftig has quit [Ping timeout: 480 seconds]
Sumera[m] has quit [Ping timeout: 480 seconds]
jasuarez has quit [Ping timeout: 480 seconds]
kusma has quit [Ping timeout: 480 seconds]
aradhya7[m] has quit [Ping timeout: 480 seconds]
KunalAgarwal[m][m] has quit [Ping timeout: 480 seconds]
zamundaaa[m] has quit [Ping timeout: 480 seconds]
doras has quit [Ping timeout: 480 seconds]
gnustomp[m] has quit [Ping timeout: 480 seconds]
kallisti5[m] has quit [Ping timeout: 480 seconds]
orowith2os[m] has quit [Ping timeout: 480 seconds]
Armote[m] has quit [Ping timeout: 480 seconds]
zzxyb[m] has quit [Ping timeout: 480 seconds]
Wallbraker has quit [Ping timeout: 480 seconds]
fkassabri[m] has quit [Ping timeout: 480 seconds]
dhirschfeld2[m] has quit [Ping timeout: 480 seconds]
knr has quit [Ping timeout: 480 seconds]
tintou has quit [Ping timeout: 480 seconds]
Ella[m] has quit [Ping timeout: 480 seconds]
nekit[m] has quit [Ping timeout: 480 seconds]
dantob has quit [Ping timeout: 480 seconds]
samueldr has quit [Ping timeout: 480 seconds]
ofirbitt[m] has quit [Ping timeout: 480 seconds]
gallo[m] has quit [Ping timeout: 480 seconds]
ohadsharabi[m] has quit [Ping timeout: 480 seconds]
DUOLabs[m] has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 480 seconds]
MotiH[m] has quit [Ping timeout: 480 seconds]
egalli has quit [Ping timeout: 480 seconds]
<HdkR>
I love that Matrix adds another layer of netsplit madness
ngcortes has quit [Ping timeout: 480 seconds]
CME has quit [Remote host closed the connection]
CME has joined #dri-devel
swick[m] has joined #dri-devel
onox[m] has joined #dri-devel
devarsht[m] has joined #dri-devel
ajhalaney[m] has joined #dri-devel
DemiMarie has joined #dri-devel
DemiMarie is now known as Guest2186
kunal10710[m] has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
ngcortes has joined #dri-devel
xerpi[m] has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]