00:20 imirkin: how is DESTDIR meant to be used? is the prefix appended to the DESTDIR, or does it replace the prefix?
00:44 orbea: imirkin: https://www.gnu.org/prep/standards/html_node/DESTDIR.html
00:45 orbea: prefix is appended
00:45 imirkin: cool
00:45 imirkin: let's hope it works out
00:45 orbea: a distro can install everything to DESTDIR and then create a package with taht directory
02:29 jekstrand: karolherbst: Not sure. Maybe generic is its own nir_var_mode?
02:29 jekstrand: karolherbst: The problem is that you have to potentially do pointer math if you ever have an access to a generic that you're not able to statically prove is a particular type.
07:48 pepp: imirkin: thanks for the notice, I'll take a look
07:48 imirkin: pepp: i think before we effectively ignored the request chroma type
07:48 imirkin: which is probably not ideal either
07:51 pepp: yes... it seems buffer_format should depend on the requested chrome_type, instead of using PIPE_VIDEO_CAP_PREFERED_FORMAT
07:56 imirkin: pepp: otoh, most drivers only support actually *decoding* to only a very specific video surface type
07:56 imirkin: so this helps applications shoot themselves in the foot
07:59 pepp: oh. So we should simply ignore chroma_type?
08:01 imirkin: dunno
08:07 imirkin: but it's what we did before, essentially
08:08 imirkin: but that won't work so well for the non-420-decoding formats
08:08 imirkin: i dunno what the right approach is
08:09 imirkin: however right now, a user program can cause an assert() to happen as a result of passing in a chroma type that's not the preferred one
08:13 pepp: imirkin: tested using mpv and a 422 file. Before the MR: the rendering is incorrect, after the MR: the assert triggers; removing the assert: the rendering is correct
08:23 pepp: imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4104
16:41 kisak: dcbaker: what's the status of mesa 19.3.5? Deferred or dropped? (not asking for it to be hurried out the door)
16:44 karolherbst: anybody interested? https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/327aaf93ce03c9ad5828b60b19942bd7f17ea3cd
16:44 karolherbst: right now I only need this for 64 bit shared atomics
16:45 karolherbst: but I can already implement other stuff if others need it
16:45 karolherbst: eh... need to adjust copyright
16:45 WoC: where would be a good place for help with opencl under mesa ? i take it, this may not be it
16:45 karolherbst: WoC: make it run on your GPU
16:46 karolherbst: We already have most of the infra in place, just depends on what GPU you have
16:47 WoC: right... ok, mesa says it's a (tag: "AMD ARUBA (DRM 2.50.0 / 5.4.0-14-generic, LLVM 9.0.1) ")
16:47 WoC: 32 bit gpu
16:48 WoC: i think my issues may be due to the os is 64 bit
16:48 karolherbst: maybe
16:48 karolherbst: that's r600, right?
16:49 karolherbst: WoC: but clover is generally also in a very bad state and right now I would assume nothing works unless proven otherwise
16:49 WoC: i have no idea, i dont know of any official cross ref tables
16:49 karolherbst: could be just a random clover messup
16:49 eschwartz: > Mesa 20.0.0 is a new development release. People who are concerned with stability and reliability should stick with a previous release or wait for Mesa 19.3.1.
16:49 karolherbst: WoC: what application are you trying to run?
16:49 eschwartz: This is a somewhat confusing message...
16:49 eschwartz: since 19.3.1 is older than 20
16:49 WoC: distributed net, opencl client
16:49 kisak: eschwartz: it's a typo, feel free to make a pull request to fix it
16:50 eschwartz: is this intended to suggest waiting for 20.0.1 then?
16:50 karolherbst: WoC: is there some demos one can test against without having to go through pain?
16:50 WoC: I dont think so
16:51 WoC: there is a benchmark option, but thatś about it and gpuinfo option
16:51 kisak: eschwartz: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/docs/relnotes/20.0.0.html#L23
16:54 WoC: karolherbst, looks like i just have to wait for someone to port cuda to amd, thanks anyway
16:54 karolherbst: WoC: well, if the benchmark options shows issue and it doesn't require any accounts or anything that's good enough
16:54 karolherbst: WoC: won't happen, and especially not for your GPU
16:55 karolherbst: ROCm already let's you support CUDA apps but not for your GPU
16:55 karolherbst: and I doubt AMD dev care all that much about CL with r600
16:55 karolherbst: I might be wrong though
16:55 WoC: anything older than 6 months...
16:56 WoC: anyway, thanks for your time
16:56 karolherbst: no idea what AMD ARUBA is though
16:56 karolherbst: could be new enough
16:56 karolherbst: dunno
16:56 WoC: it's an apu
16:56 WoC: A8
16:57 WoC: A8-5500 i think
16:57 karolherbst: you might want to check if ROCm runs on that one
16:57 karolherbst: should cause less issues if it does
16:57 kisak: ARUBA is a Northern Islands chipset, when they went to VLIW4 and just before the ATi chips were dropped
16:57 karolherbst: but it sounds like it's too old
16:58 karolherbst: ahh
16:58 WoC: lspci lists it as 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7560D]
16:58 karolherbst: yeah, ROCm only runs on GCN
16:58 WoC: Got rocm running (finally) on a A10-
16:59 WoC: A10-9620P
17:00 WoC: bet for the A8-5500, rocm would call it a 3rd different name
17:02 WoC: karolherbst, how would i know which is GCN or not ?
17:03 WoC: Given the many names used for the same device...
17:04 WoC: Looks like i just have to reinstall windows on it so i can have opencl
17:05 karolherbst: for now, yes
17:05 WoC: Think there will be any sort of timeline for rocm to become stable ?
17:06 karolherbst: no clue, but I think it's simply that your GPU is too old, so they don't care
17:06 WoC: Checking as I have several APUs/GPUs
17:08 WoC: From what I've seen performance wise, rocm is worse than the standard opencl in windows ( that comes with the driver )
17:08 WoC: anyhow, have a great one
17:22 kisak: can a channel mod please block uis for ~10 minutes, their internet and/or irc client is broken
17:23 karolherbst: kisak: huh?
17:23 karolherbst: that's harsh to block somebody if your client can't ignore leave/join messages for certain people
17:23 karolherbst: every good client should have a feature to hide those for people not participating in the chat
17:24 kisak: the request is just to bump them off of whatever auto-reconnect is happening
17:24 kisak: not something long term
17:25 karolherbst: there are good enough workarounds for that on clients
17:25 karolherbst: for me all join/part whatever events are hidden except that person did something within the last 24 hours
17:27 karolherbst: anyway, connection issues happen, be it crappy ISP, mobile network messup, somebody traveling... requesting to block somebody because of that sounds foolish to me
17:30 kisak: fine, I won't make a request like that again. This isn't worth having a disagreement about
17:31 eschwartz: It is a pretty well-known thing in freenode in general to ban such people with a ban forward to ##fix_your_connection
17:32 eschwartz: which even comes with helpful instructions on how to fix the issue, and makes it obvious when reading the channel ban list that it's the kind of ban that is okay to drop at any time
17:32 eschwartz: it's not a *punishment
18:00 karolherbst: eschwartz: people could also just use non broken IRC clients and don't get bothered by those messages at all
18:01 imirkin: karolherbst: difference between can't and doesn't
18:01 imirkin: it's fairly annoying
18:01 imirkin: but also interesting to know when people leave/join
18:01 imirkin: so when someone spams the channel for 24h with such messages, it gets frustrating
18:02 karolherbst: sure.. but my client only shows leave/join messages for people active in the channel which is enough
18:02 karolherbst: if somebody writes nothing for weeks, it never gets displayed. If they write something and get disconnected, I see it
18:02 imirkin: suppose i could ignore him, but seems harsh
18:03 imirkin: it happens with active people too sometimes
18:03 karolherbst: sure, but the timer resets when they rejoin and write nothing
18:04 karolherbst: anyway, I was neither annoyed by displayed nor missed leave/join messages for years now
18:10 malice: Uh
18:10 malice: # C [radeonsi_dri.so+0x563e57] nouveau_drm_screen_create+0x229eb7
18:10 imirkin: look at the offset, that's just unwinder fail
18:11 malice: Ah, ok
18:11 imirkin: those functions are all like 5 lines long
18:11 imirkin: 0x229eb7 from the start of that function feels like a jump to a random-ish address
18:13 malice: Basically, entering a ship in starmade causes a segfault and a big fancy error, and that. :P
18:14 karolherbst: malice: you can rechech with gdb
18:14 karolherbst: it usually prints the real value
18:14 karolherbst: or... maybe just report the bug :)
18:15 malice: karolherbst: Well, the game has had invalid shaders and shit before
18:15 karolherbst: nice, OpenCL atomic tests: PASSED 13 of 13 tests. :)
18:15 karolherbst: malice: uff... well, yeah... I guess then random things can happen
18:15 malice: Including missing version line
18:18 malice: Hmm, doesn't happen on low settings
20:55 austriancoder: what is needed to go from glsl 120 to glsl 130?
20:56 imirkin: 10
20:57 imirkin: proper integers, texelFetch / other advanced texturing functions, xfb, mrt, bunch of texture formats
20:58 imirkin: you can look at the exts that make up GL 3.0 -- it's not 100% accurate, but it's pretty close: https://people.freedesktop.org/~imirkin/glxinfo/#p=compat
20:59 austriancoder: imirkin: nice site
20:59 imirkin: fairly out of date - couldn't get people to provide the data
20:59 imirkin: but the ext list is accurate :)
21:01 imirkin: another fun one not on the list is msaa
21:02 imirkin: that's fungible though -- freedreno just flat out lies about it for earlier gens
21:29 robclark: imirkin: with a bit more drm-shim, and scripting away the manual fixups to update glxinfo page, we could automate updating that page in CI with a scheduled pipeline job (ie. run every night on master, or something like that)..
21:30 imirkin: send patches
21:30 robclark: imo that would be way more useful than mesamatrix
21:30 robclark: heheh, fair
21:30 imirkin: i've lost interest for the most part, but happy to fix up the parser and/or whatever else in the js
21:40 karolherbst: robclark: any idea how it looks like in regards to atomic support in hw on adreno?
21:41 karolherbst: like 64 bit atomics on global/shared/etc.. memory and stuff
21:42 karolherbst: imirkin: btw, do you know what was failing for f32 add atomic in nvc0? Or was that just me running into odd issues
21:43 robclark: karolherbst: there isn't any "real" 64 b instructions.. not sure what atomic instructions do if I try to use them on a vec2.. but also by far not biggest priority right now
21:44 karolherbst: robclark: mhhh... wondering if you have a 64b atomic cas or something
21:45 robclark: if I had time for opencl, my first patch would be support for embedded profile so I didn't have to care about 64b ;-)
21:45 karolherbst: well those atomics are optinal anyway
21:45 karolherbst: robclark: I am mainly asking because I wrote a nir lowering pass anyway, but maybe you can even use it for f32 add or something
21:46 karolherbst: we know that we don't have a f32 add on shared memory eg
21:46 robclark: ahh, well still, lowering all 64b to 32b doesn't seem like it will be pretty
21:46 karolherbst: but there is a gl ext for it
21:46 imirkin: karolherbst: you mean f32 add? the issues were in the shared lowering for gm107
21:46 karolherbst: imirkin: I meant rather what tests were failing
21:46 imirkin: don't remember
21:46 imirkin: presumably the ones ian wrote
21:47 karolherbst: my codegen implementation was working quite well and it reused the cas return value instead of loading again
21:47 imirkin: NV_shader_atomic_float is the ext
21:47 karolherbst: but... and 64 kind of messed it all up
21:47 karolherbst: could just move some code around though