14:11 NanoSector: hey, I was just playing with the Dolphin emulator, and trying to launch a game with it causes my GPU to hang. trying to reclock it results in this message in dmesg: https://hastebin.com/cukejiqajo.go
14:11 NanoSector: reclocking normally works fine
14:52 imirkin: NanoSector: probably reclocks after hang aren't such a great idea?
14:52 imirkin: the warn appears from a runtime suspend though
14:52 imirkin: so nothing to do with a reclock
14:53 NanoSector: well i wasn't sure if dolphin was hanging, so i reclocked to see if the gpu responded
14:53 imirkin: but yeah, if the gpu is hung, then all kinds of stuff will fail
14:53 NanoSector: which it does not
14:53 NanoSector: just now even going to the details page of gnome-control-center froze my system
14:53 imirkin: you can unload and reload nouveau... that sometimes works
14:53 imirkin: unless the X server has a handle on it
14:53 NanoSector: i run wayland when i can, but i bet dolphin runs under xwayland
14:54 orbea: i wonder if your experience would be any better with just xorg?
14:54 NanoSector: it's funny, since I played a session of half life 2 for a few hours with nouveau and it was just fine even with a reclock, but dolphin immediately hangs it
14:55 NanoSector: orbea, no harm in trying i suppose
14:55 NanoSector: off to the Xorg mobile
14:56 NanoSector: yegh xorg feels so sluggish after using wayland
14:56 orbea: heh
14:56 NanoSector: neup dolphin hangs
14:56 orbea: oh well
14:58 imirkin: HL2 is a much simpler GL program than dolphin
14:59 NanoSector: heh, my system hung, then it unfroze for a moment and it hung again
14:59 imirkin: NanoSector: what gpu btw?
14:59 NanoSector: a GTX 950M in a laptop with HD Graphics 620
14:59 NanoSector: sorry, didn't mention
15:00 NanoSector: this is on kernel 4.13.5, but i think the trace i posted already told you
15:04 orbea: i rebuilt the dolphin master and it still works here.
15:05 NanoSector: interesting
15:05 orbea: must be connected to your specific hardware or setup.
15:05 NanoSector: perhaps
15:06 NanoSector: i'm using a build up to commit 2dfbf866fb, which is about 4 days ago
15:06 NanoSector: https://github.com/dolphin-emu/dolphin/commit/2dfbf866fb7ea70cf23f402b5106f5b38324a8e1 this one
15:06 orbea: I was on 2017.09.25_38a8d04 and now am on 2017.10.11_2dfbf86
15:06 NanoSector: that's the same commit
15:06 NanoSector: hmm
15:07 orbea: i guess nothing was pushed since then
15:07 NanoSector: there wasn't
15:08 imirkin: NanoSector: erm, which gpu is that? i.e. which chip?
15:08 NanoSector: oof now you're asking me something :x
15:08 orbea: according to the nouveau codepage GM107
15:09 NanoSector: i always get confused with GK107 and GM107, GK was my previous GPU (750M)
15:09 orbea: lspci should know
15:10 NanoSector: 01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 950M] (rev a2)
15:34 NanoSector: hmm abrt caught two crashes in xorg-x11-drv-nouveau
15:37 NanoSector: this dmesg is from when it hung after opening gnome-control-center: https://hastebin.com/nopegibase.sql
15:39 NanoSector: and i have no idea what i was doing here, but something with dolphin: https://hastebin.com/anomurefez.sql
15:45 karolherbst: NanoSector: did you disable the ubershaders?
15:45 NanoSector: karolherbst, yes
15:45 orbea: ubershaders work here too btw...
15:45 karolherbst: yeah, I know, but sometimes they can be too much for the GPU, maybe
15:45 orbea: sometimes very slowly... :P
15:45 NanoSector: ubershaders don't work on intel opengl here either
15:45 NanoSector: really odd
15:46 karolherbst: NanoSector: last line of pstate on highest pstate?
15:46 NanoSector: sec
15:46 karolherbst: maxwells are kind of funky, because they use higher clocks than kepler and I know we don't do so well with high clocks
15:46 NanoSector: wtf 'DRI_PRIME=1 glxgears' gives me a black window
15:47 NanoSector: https://hastebin.com/acuqatilag.go
15:48 karolherbst: well, your GPU is messed up, what do you expect
15:50 NanoSector: and it froze my system again
15:50 NanoSector: karolherbst, the 0f line is 0f: core 270-928 MHz memory 5010 MHz
15:50 NanoSector: i'll try to get the last line
15:51 karolherbst: mhh, if 928 is the max, then it should be fine
15:51 NanoSector: it's no use, glxgears is just black
15:51 karolherbst: NanoSector: does it work on lower clock levels?
15:51 NanoSector: it's running at the lowest now
15:51 NanoSector: and it doesn't work
15:51 NanoSector: 0f: core 270-928 MHz memory 5010 MHz
15:51 NanoSector: AC: core 405 MHz memory 810 MHz
15:52 karolherbst: I think you need to reboot
15:52 NanoSector: after echoing 0f to pstate:
15:52 NanoSector: 0f: core 270-928 MHz memory 5010 MHz AC DC *
15:52 NanoSector: AC: core 0 MHz memory 0 MHz
15:52 wikdhw: karolherbst: could you help out with https://bugs.freedesktop.org/show_bug.cgi?id=102349 ?
15:53 karolherbst: NanoSector: and you can't reclock while the GPU is suspended
15:53 karolherbst: wikdhw: I don't have such a GPU
15:53 wikdhw: its about 1-3$. if that would fix the problem, i would even send you such a card
15:55 karolherbst: but I think skeggsb or imirkin are currently the ones better suited for fixing this issue
15:56 wikdhw: is there a better way to contact skeggsb then filling up a bugreport or trying to contact him over IRC? Should i write him a email?
15:57 wikdhw: did you maybe have some idea about this problem here? https://bugs.freedesktop.org/show_bug.cgi?id=102430
15:58 karolherbst: wikdhw: you run out of vram
15:58 karolherbst: I think
15:59 wikdhw: this is how that looks like? because then i should not have critical memory errors and then the whole system crashes
15:59 karolherbst: well, it depends
15:59 karolherbst: all that stuff isn't really well handled on nouveau
15:59 karolherbst: it you run out of vram, bad thinks can happen
16:00 karolherbst: even yor window manager could run out of it, because some other applications just claimed every last bit
16:00 imirkin: wikdhw: making modern desktop environments work well on nouveau / nv4x is probably a multi-month endeavor.
16:00 karolherbst: I actually wanted to work on the memory managemt part at some point, and maybe I even have to to support certain features
16:01 wikdhw: karolherbst: that would be awesome if those memory handling problems could be fixed
16:01 karolherbst: well, then you will run into other issues sadly
16:02 karolherbst: it's not like nobody wants to fix this, it's just time is limited and there are dozens of other issues as well
16:02 wikdhw: imirkin: but the system should not screem the dmesg with errors and freeze up when i run supertuxcart on LXDE, right?
16:02 karolherbst: _maybe_
16:02 imirkin: wikdhw: apparently it does though
16:03 karolherbst: and LXDE just uses the core of plasma5 anyway
16:03 wikdhw: imirkin: thats why i reported that :)
16:03 imirkin: stk has had a ton of changes which have made it not run well on weaker gpu's
16:03 karolherbst: there is not much of a difference in LXDE and Plasma5
16:03 karolherbst: try xfce4 instead
16:03 karolherbst: lxde is basically a plasma5 without fancy features
16:03 karolherbst: well
16:03 karolherbst: lxqt
16:04 karolherbst: except you run the "old lxde"
16:04 wikdhw: imirkin: you had send this patch that fixed a mesa-bug https://bugs.freedesktop.org/attachment.cgi?id=133733 . You liked to redo it propperly next days. It would be great if you could maybe have today a look into it
16:05 imirkin: wikdhw: yeah, my time for open-source stuff is basically non-existent. i'd need to properly analyze what was going on before making a proper patch.
16:05 wikdhw: karolherbst: i ran the GTK2 based LXDE. not lxqt that is based on Qt instead of gtk
16:06 imirkin: the death with stk is something i've run into before with gpu's that don't have a lot of vram
16:06 karolherbst: imirkin: nouveau doesn't swap memory, does it?
16:07 imirkin: it's all variously complicated in different ways on different generations.
16:07 wikdhw: karolherbst: it would be great if you could pick up such a pci-e card. You could probably make way better bugreports about that then i can do :)
16:07 imirkin: wikdhw: it's not about the quality of the bug report. it's about the lack of time to do anything about it.
16:07 karolherbst: wikdhw: I would rather have new people coding on nouveau, that's why I would rather convince you to help out yourself :P
16:08 wikdhw: karolherbst: i am not able to code and i dont know why, but i am also not able to learn coding. I am extremely bad at that
16:10 karolherbst: well, it is all about what you want to do. If you don't want to code, that's fine. Just saying that I think it is more important to get new people on board with nouveau, because currenty it doesn't look so well
16:11 wikdhw: karolherbst: could you get such a cheap card? would be really great to have a developer with such a card that see the errors on the machine he is running at his desk :)
16:12 wikdhw: if you like i can send you such a card. just tell me your postal address.
16:13 karolherbst: wikdhw: again, the problem isn't having access or anything. I am sure I won't be able to look into your issue that soon either. Faking out of memory situations is quite easy on any card, so this isn't the problem. I mainly said, it could be possible that I will need to work on that out of memory thing anyhow, but not because of your issue
16:13 karolherbst: sorry, but that's how it is currently
16:15 karolherbst: imirkin: I assume that if we want to swap to system ram, or at least allocate system ran if we are out of vram, requires some changes in mesa as well? Or could we simply allocate everything in sysram?
16:15 karolherbst: currently thinking if it's a big enough for a gsoc/evoc project
16:16 imirkin: there are a lot of hurdles to making this stuff "work well"
16:17 karolherbst: well, I am not talking about moving already allocated memory
16:17 imirkin: some are technical, e.g. tesla's don't support large pages in sysram
16:17 imirkin: others are practical, i.e. how to implement any policy
16:17 karolherbst: I would go for the most trivial: if no vram, use sysram
16:17 karolherbst: that's already better than what we currently have
16:18 imirkin: we kinda do that... via libdrm
16:18 imirkin: i think
16:18 karolherbst: for everything?
16:18 imirkin: "no vram" is kinda a tricky concept to nail down
16:18 imirkin: since it all has to do with what's being used by the currently-executing thing
16:18 karolherbst: yeah, I was kind of interested in getting memory usage reported to userspace
16:19 imirkin: and stuff is swapped in and out as needed
16:19 imirkin: but if you ever need more than total vram for one draw, you're kinda SOL
16:19 karolherbst: but the GPU can access sysram in a draw, right?
16:20 karolherbst: or at least for _some_ stuff inside a draw
16:20 imirkin: sure
16:20 imirkin: but let's say you put a texture in vram
16:20 imirkin: and used large pages for it
16:20 imirkin: you can't just point that VA to sysram on tesla
16:20 imirkin: with pre-G80 you have relocs to be able to fix stuff up but even then it can be tricky
16:21 karolherbst: I see
16:21 karolherbst: so for fermi+ it would be easier to do for now
16:23 imirkin: yeah
16:23 imirkin: for fermi the kernel can take care of it
16:23 imirkin: except it can't because we do all our allocations with forced-vram or forced-gart
16:23 imirkin: and some things really *do* need to be in vram
16:23 imirkin: but most things are just faster when they're in vram
16:24 imirkin: so like render targets ... you *really* want those in vram
16:24 imirkin: esp if there's blending
16:25 imirkin: some stuff like the code cache i suspect *have* to be in vram
16:26 imirkin: and prolly the tic/tsc tables
16:27 imirkin: G80 doesn't supported tiled textures in sysram
16:27 imirkin: like i said... it's a non-trivial problem ;)
16:29 karolherbst: right
16:29 imirkin: before every gpu had infinity vram, software was a lot more cognisant of these limits and tried not to run over them
16:29 karolherbst: but in worst case, we could move everything which doesn't have to be in vram into sysram and hopefully we can move on
16:31 karolherbst: imirkin: I guess it would make sense to add a preference to the memory allocation? I really don't know how much we need to split stuff, but usually we need something like: where is it allowed to be, which location is preferred. But I could assume that vram is always preferred, or is there something which should be rather in sysram?
16:31 imirkin: yeah
16:32 imirkin: and i think you can do that now -- you can pass in VRAM | GART when creating a bo
16:32 karolherbst: I could imagine some buffer stuff, where the application reads back memory
16:32 imirkin: but i don't think there's a way to specify "prefer vram"
16:32 imirkin: also it's not a buffer that has this preference
16:32 karolherbst: well, we only need this, if sometimes vram isn't prefered
16:32 imirkin: it's the *use* of the buffer
16:32 karolherbst: ohhhh
16:32 karolherbst: right
16:32 karolherbst: makes sense
16:32 imirkin: so sometimes it's ok for that buffer to be in vram, other times not
16:32 imirkin: er. gart. wtvr.
16:33 karolherbst: but maybe a preference makes actually sense, for some things it doesn't really matter, and some stuff should be really in vram
16:35 karolherbst: anyhow, I really would like to have like 10 gsoc/evoc tasks written inside the wiki, having 3 sounds like not enough
16:39 imirkin: go for it.
16:39 imirkin: i can't be a mentor for any of them though.
16:43 karolherbst: k
19:05 Fervi: Hello. I think this is trivial bug. One sensor (from nvidia - i think) shows ALARM, because temperature is too low (59.5*C, but "low" is 70*C)
19:06 karolherbst: .... fun
19:10 karolherbst: imirkin: ohh you actually wrote a trello card for that resolve thing: https://trello.com/c/jzBpfrzL/134-resolve-on-transfermap-upscale-on-transferunmap
19:10 imirkin: :)
19:11 imirkin: just 2 years ago.
19:11 karolherbst: :D
19:17 karolherbst: I am so totally hyped for next month...
20:47 ecobos: imirkin: hey, it's me again... Thanks for recommending the kernel upgrade, it got rid of a bunch of stuff. Still have those reproducible faults at startup, but I guess it's pretty hard to ask for it to get fixed, so I'll ask another thing instead... How can I help? I'd love to get involved and help out a bit (as long as work allows it), and maybe that way I could eventually fix that bug myself :)
20:48 karolherbst: ecobos: we have a trello board with several tasks: https://trello.com/b/ZudRDiTL/nouveau
20:49 karolherbst: or come up with something you think is still missing in nouveau and work on that
20:50 karolherbst: and there are several bugs on bugzilla which may or may not affect you
20:50 karolherbst: and if you found something which got your attention, we could help you with that (eg: which project it applies to, etc..)
20:50 ecobos: karolherbst: heh, just saw that in the backlog, that's why I dared to ask :). I guess the "easy" tasks are kinda suitable for beginners? I could go through them and see which ones of them look more tractable
20:51 karolherbst: kind of yes, but sometimes mediaum/hard tasks can be fairly simple, but super time consuming
20:51 ecobos: karolherbst: sounds good, thanks! Are there any docs for setting up an environment or something like that?
20:51 karolherbst: and easy ones can be done in a short amount of time, but require a lot of understanding
20:51 ecobos:can try to dig it up instead of draining time from you
20:51 karolherbst: ecobos: we have a wiki, but pages are usually outdated: https://nouveau.freedesktop.org/wiki/
20:52 karolherbst: playing around is always a good plan, but usually it requires knowledge in what is relevant
20:52 karolherbst: a nice thing to begin with is the compiler, because it is fairly easy to play with and debug
20:53 karolherbst: but this won't help you with other stuff
20:53 karolherbst: so you should rather decide what you like and we could go from there
20:54 ecobos: karolherbst: I see. I guess I'd be fine with "whatever I could be more useful at", but that depends on a lot of stuff... I have a somewhat ok-ish understanding of the high-level mesa tree, if it helps, less about the kernel-side of stuff... Anyway, I'll give it some thought and reach back sometime soon, thanks a lot!
20:55 ecobos:bookmarks trello board, goes get some sleep
20:55 karolherbst: ecobos: within mesa is the command submission and compiler stuff basically
20:55 karolherbst: and the compiler needs a lot of work still
20:56 karolherbst: helping out with fixing CTS tests might be good
20:56 karolherbst: ecobos: we have a seperate CTS board: https://trello.com/b/lfM6VGGA/nouveau-cts
20:56 karolherbst: and I track the CTS fails on this card: https://trello.com/c/qtJ5jkZh/13-cts-master-45-status
20:57 karolherbst: enabling parallel_shader_compile would be a fun project
20:58 ecobos: karolherbst: CTS is all the piglit tests? I recall running those in the past, so I could maybe look into some of those and try to help out...
20:58 karolherbst: CTS is the khronos stuff
20:59 karolherbst: https://github.com/KhronosGroup/VK-GL-CTS
20:59 karolherbst: but fixing piglit tests is also fine
20:59 ecobos: Oh, I see
20:59 ecobos: Thanks, will try to get a proper setup and reach back
21:01 karolherbst: I did a nearly full piglit run a while ago... will upload the newest resulsts here shortly: https://mini.karolherbst.de/nouveau/piglit/nve6-cts/
21:01 karolherbst: well this page is more interesting: https://mini.karolherbst.de/nouveau/piglit/nve6-cts/problems.html
21:02 ecobos: What's the best way to test for regressions? For example, if I do a change that fixes a test, how can I know it won't break others? Should I run the whole testsuite? Do they run automatically somewhere?
21:03 karolherbst: run the whole, yes
21:03 karolherbst: we don't have automatic stuff yet, but I plan to set something up over the next months
21:03 ecobos: ok, makes sense, thanks again!
21:13 karolherbst: updated: https://mini.karolherbst.de/nouveau/piglit/nve6-cts/problems.html
21:14 karolherbst: with 17.1.10 and 17.2.2 results
21:18 imirkin: ecobos: what GPU do you have again? and what kinds of things do you think you're able to do?
21:19 ecobos: imirkin: NVIDIA Corporation GM107GLM [Quadro M2000M]
21:20 imirkin: oh cool. wait, are you, NanoSector?
21:20 ecobos: imirkin: nope
21:20 ecobos: imirkin: and re. what I'm able to do... I like to hack on web browsers (mostly Gecko / Servo these days), and those are a fairly different beast from a graphics drivers, but my idea is to learn :)
21:20 imirkin: ok. i don't recognize your handle. my memory must be going.
21:20 imirkin: [or was never there to begin with]
21:21 imirkin: ok, but like ... programming, yes? c/c++?
21:21 ecobos: heh. FWIW I don't think I've been here too often, more than idling and reporting stuff about a month ago
21:21 ecobos: imirkin: yeah, c / c++ / rust
21:21 imirkin: cool
21:21 imirkin: well, graphics driver stuff isn't much different than a web browser in so very many respects
21:22 ecobos: github.com/emilio, fwiw, if it helps to get an idea of what I work on lately
21:22 imirkin: for volunteer contributions, it's probably best to find an area that you're interested in and able to work on
21:22 imirkin: one thing that comes to mind as missing for GM107 is the vdpau-based accel of video decoding
21:23 imirkin: having some basic concepts of how video works would be a good prereq for that though
21:23 karolherbst: and having a lot of time
21:23 imirkin: also, some stuff has come up recently where e.g. we make it work on older gens, but then don't have time/whatever to do it for maxwell
21:23 imirkin: so that'd be useful, albeit less interesting
21:24 imirkin: something that's a little tedious but otherwise moderately straightforward is adapting the fp64 code that dboyan wrote for maxwell
21:25 imirkin: basically it's "take these operations, and convert them into something the assembler will be happy with for maxwell"
21:25 ecobos: I think whatever gets me going would be useful, I use to find my way once I work on something. That stuff sounds interesting certainly
21:25 imirkin: should introduce you to some of the ops that are out there, but not require a super-deep understanding of what's going on
21:25 imirkin: https://github.com/imirkin/mesa/commits/cts
21:25 imirkin: have a look at the fp64 commits from dboyan there
21:25 karolherbst: imirkin: I think the biggest challange here is to fight with the assembler name differences and other silly differences
21:26 imirkin: basically we need that for maxwell
21:26 imirkin: karolherbst: yeah, it's not like a super-difficult task
21:26 karolherbst: imirkin: what is the status of the bindless patches by the way?
21:26 karolherbst: sorry if I asked that question the fifth time ...
21:26 imirkin: did i push them? i forget.
21:26 karolherbst: doubtful
21:27 karolherbst: or maybe?
21:27 imirkin: oh right, i was going to push without flipping the feature on
21:27 karolherbst: ahh
21:27 imirkin: but probably never got around to it?
21:27 karolherbst: dunno
21:27 ecobos: imirkin: I think that'd be a decent first task to get a feel of the code around, and to get me reading some docs
21:27 imirkin: ecobos: there's not a ton of docs, but feel free to ask here
21:27 karolherbst: ecobos: I doubt that fp64 thing will get you to anything of that
21:27 karolherbst: sadly
21:27 ecobos: heh
21:28 karolherbst: ecobos: I did the same for kepler1: https://github.com/karolherbst/mesa/commit/93b1b13a33ee14b95e8e190252d191207d10db1a
21:28 imirkin: in my estimate, that task should take someone who knows what they're doing 1-2h. there's a ton of stuff to learn to get to that stage, so don't feel bad if it takes you several days.
21:29 karolherbst: ohh, the sched stuff is different
21:29 imirkin: karolherbst: btw, cts has gotten some fixes for a few of the varying locations things
21:29 karolherbst: this will be fun for ecobos
21:29 imirkin: karolherbst: 0x7e0 to the rescue ;)
21:29 karolherbst: ;D
21:30 karolherbst: imirkin: the last week?
21:30 imirkin: karolherbst: yeah
21:30 imirkin: i think so
21:30 karolherbst: but mhh, I didn't run the master CTS for a month or so now
21:30 karolherbst: more occupied with the last released version
21:31 karolherbst: I really hope I find enough time to work properly on CTS next month, I really do
21:31 ecobos: imirkin: Hmm, ok, I can give it a try. Any test that I should run that should exercise that?
21:32 karolherbst: ecobos: there are some fp64 tests in the CTS
21:32 karolherbst: KHR-GL45.gpu_shader_fp64.*
21:32 imirkin: karolherbst: hm crap. that bindless stuff was pretty hacky =/
21:33 imirkin: lock2... good times.
21:33 ecobos: karolherbst: k, let's see if I get those working on my GPU
21:33 karolherbst: ecobos: do you have a second machine?
21:33 ecobos: karolherbst: yup, why the question?
21:33 karolherbst: chances are high, that your entire system will hang if you run the entire CTS
21:34 ecobos:didn't plan to destroy his :)
21:34 karolherbst: also for a complete run you kind of need my CTS branch
21:34 imirkin: just run those tests
21:34 imirkin: don't bother with a full run
21:34 ecobos: Yeah, my plan was running those for now, seemed like self-contained enough
21:34 karolherbst: and this patch https://github.com/karolherbst/mesa/commit/96b4cfeb8d7f633eaedad23506b5fd9c70002673
21:35 ecobos: But we'll see
21:35 imirkin: ah yeah. you do need that.
21:35 karolherbst: or use the LIBGL_VERSION_X_OVERRIDE variables
21:35 imirkin: or an override env var.
21:35 imirkin: MESA_GL_VERSION_OVERRIDE + MESA_GLSL_VERSION_OVERRIDE :)
21:35 karolherbst: imirkin: also, did you find some time to look over that dubios codegen patch I cleaned up?
21:35 ecobos: sounds good!
21:36 imirkin: you mean tobijk's patch for defs becoming a set?
21:36 ecobos: imirkin: karolherbst: thanks both, really! :)
21:36 karolherbst: ecobos: https://github.com/KhronosGroup/VK-GL-CTS/blob/master/external/openglcts/data/mustpass/gl/khronos_mustpass/4.6.0.x/gl45-master.txt
21:36 karolherbst: a list of all relevant CTS tests
21:36 karolherbst: search for the KHR-GL45.gpu_shader_fp64.* ones
21:36 karolherbst: no idea if CTS supports wildcards or so
21:37 imirkin: it does.
21:37 karolherbst: you can also create your own file and pass --deqp-caselist-file= to glcts
21:37 ecobos: I see
21:38 ecobos:keeps IRC log, goes get some sleep (CET)
21:38 ecobos: cheers
21:38 karolherbst: imirkin: I am quite sure that this is still a hack, but I think it shows why stuff goes south without that patch: https://github.com/karolherbst/mesa/commit/78599dfa2eaef1c366aa284742dc6c71e3b68a5e
21:38 karolherbst: I am sure we end up with doubled entries
21:38 imirkin: ecobos: see ya. this chan is logged too btw - check chan topic.
21:39 imirkin: karolherbst: the getInsn() thing feels buggered. why was that not necessary before?
21:40 imirkin: karolherbst: is getInsn being used during RA?
21:40 imirkin: [or after]
21:40 karolherbst: no clue
21:40 karolherbst: defs.front() is the new "(*it)->get() == this" though
21:41 karolherbst: so technically the code does still the same, kind of
21:41 imirkin: getInsn used to be fast and it's not anymore.
21:41 karolherbst: yeah
21:41 karolherbst: still, compiler got faster
21:41 imirkin: can you not just grab any random one from the set?
21:41 karolherbst: I didn't want to change behaviour
21:42 karolherbst: maybe any would be good enough, who knows
21:42 karolherbst: maybe it isn't
21:42 karolherbst: front is a special case and I am sure some code depends on that
21:42 karolherbst: maybe not
21:42 karolherbst: anyhow, with that commit I don't have any regressions
21:43 karolherbst: which was my motivation in th first place to clean the original version up, because it broke stuff
21:44 karolherbst: imirkin: I was already thinking about to add a variable to store the previous "front()" value
21:44 karolherbst: then getInsn should be fast again
21:45 imirkin: why can't it just grab a random element from the defs set?
21:46 imirkin: it'd be interesting to try and see if antyhing in shader-db changes
21:46 karolherbst: I could try to do that and see how it goes
21:46 imirkin: if not, i'd call it a day
21:46 imirkin: although it'd be nice if it could assert
21:46 imirkin: on RA having started
21:46 imirkin: after which getInsn() should not be used
21:46 karolherbst: ahh
21:46 imirkin: that's why i had tobijk do it separately
21:46 karolherbst: makes sense
21:46 imirkin: i think you merged the two functions?
21:47 karolherbst: he had a getUniqueInsnMerged function
21:47 imirkin: yeah...
21:47 karolherbst: but this entire get*Insn* think he wrote was buggy and broke a lot of stuff
21:47 imirkin: all the other functions should not be getting called after RA merges defs together
21:47 karolherbst: and I wanted to simplify his patch a lot
21:47 imirkin: i have no problem with simplification ;)
21:48 karolherbst: so getInsn shouldn't be called after RA starts, well, I am sure it is though
21:48 karolherbst: or at least now with that patch
21:48 karolherbst: see the last change
21:51 imirkin: i don't think it should be?
21:51 imirkin: but maybe it is?
21:51 imirkin: i'll be honest with you - i dunno :)
21:51 karolherbst: fair enough
21:52 karolherbst: I am quite okay with the patch how it is now, because it makes it possible to run the full CTS and nothing inside piglit breaks
21:53 karolherbst: I could write a patch to properly fix the real issue though
21:54 karolherbst: and I am sure we just add duplicates into defs
21:54 karolherbst: and this makes the runtime so horribly slow
21:55 karolherbst: and also to depend on a hashing algorithm makes me uneasy anyhow
21:55 karolherbst: *feeling
21:55 karolherbst: allthough maybe the pointer is the hash value itself for pointers, dunno
21:56 NanoSector: <imirkin> oh cool. wait, are you, NanoSector?
21:56 NanoSector: lol
21:57 imirkin: NanoSector: he also had a GM107.
21:57 karolherbst: ohh wait, it does a double check with operator==, what every hased set should do
21:57 NanoSector: yeah, i noticed
21:57 NanoSector: could've been me
21:57 imirkin: who knows how many of you there are runnign around :p
21:57 NanoSector: lol