00:47 mlankhorst: imirkin: just trying to get my h264 webcam streaming
00:47 mlankhorst: right now if it hangs it reboots after an hour or so it seems
00:47 mlankhorst: watchdog would cut it a little bit :)
02:14 karolherbst: mupuf: ping
02:55 karolherbst: RSpliet: okay, I think I got a little further: the timeout happens somewhere between the pmu got the message and the kernel dispatching the reply
03:40 gothos: Hello!
03:41 gothos: I've a problem with my new Fedora 23 installation, I was previously using the binary nvidia driver and switched to nouveau with the new release.
03:41 gothos: I have a GTX 960 and everything is quite slow. Xorg log says: AIGLX: Screen 0 is not DRI2 capable AND AIGLX: reverting to software rendering
03:43 pmoreau: gothos: Check that you use the xf86-video-modesetting package rather than xf86-video-nouveau
03:43 pmoreau: And which kernel version are you using?
03:43 RSpliet: and is mesa-libGL and mesa-libGLX installed properly
03:43 gothos: pmoreau: 4.2.5-300.fc23.x86_64
03:43 pmoreau: Note that you won't get any acceleration with that card
03:43 gothos: I'll check the packages :)
03:43 pmoreau: Should be recent enough :-)
03:44 RSpliet: pmoreau: oh right, 960...:-P
03:44 gothos: So, software only in any way?
03:44 RSpliet: gothos: yes, for now you're much better off with the official driver
03:46 gothos: RSpliet: I see. :( Guess I'll just have to wait then, since there is no nvidia driver for the new Xorg version available yet
03:46 gothos: But thanks guys! :)
03:50 karolherbst: gothos: mhh for 1.18?
03:50 karolherbst: gothos: try Option "IgnoreABI" "1" in ServerFlags
03:50 karolherbst: might or might not work
03:58 gothos: People on reddit were claiming that that did not work, tho apparently there is a repo at http://negativo17.org/nvidia-driver/ that has a working binary driver (untested my myself so far). Just for the log. :)
04:11 mupuf: karolherbst: pong
04:11 karolherbst: mupuf: did you read my message about interrupts going lost?
04:11 mupuf: rebooting on the latest xserver and I will be free to answer you
04:11 karolherbst: nice
04:14 kwizart: gothos, don't rely on this repo ever, the real community repo is at rpmfusion.org
04:14 kwizart: gothos, that been said, nvidia binary driver is NOT compatible with the xorg-server in fedora 23, so you need to wait for nvidia to release one
04:15 mupuf: karolherbst: ok, everything seems to be working fine
04:15 mupuf: so, let's have a look at this command submission issue
04:16 karolherbst: well, the interrupt is going lost only sometimes
04:16 karolherbst: I ran my reclocking loop without any sleeps
04:16 karolherbst: and it works for aroun 20k+ switches without problems usually
04:16 mupuf: I doubt they do, I guess what happens is that the code dealing with the IRQ is not safe
04:17 karolherbst: could be
04:17 karolherbst: but when I quit the loop
04:17 karolherbst: and do new stuff with the pmu
04:17 karolherbst: it suceeds sometimes
04:17 mupuf: as in, yeah
04:17 mupuf: what may happen is this
04:17 karolherbst: usually it always woirks when I do the same thing over and over again
04:17 karolherbst: but not when I do something different
04:18 karolherbst: I have a little workaround patch so that the kernel driver won't be messed up that hard anymore: https://github.com/karolherbst/nouveau/commit/bd1328b4a7868160263c88438f9bce795cda72ef
04:18 karolherbst: it allows the module to be reloaded
04:18 karolherbst: and the pmu works fine then
04:18 karolherbst: otherwise there would be a kworker infinitly blocking and the module can't be removed
04:19 mupuf: the pmu receives an irq, clears it after reading the message but another IRQ arrived right before the value is cleared
04:19 mupuf: this means you just silenced an IRQ
04:19 mupuf: having a timeout is definitely a safe idea :)
04:20 mupuf: let's have a look at the command submission
04:20 karolherbst: I am not saying the patch handles the timeout path the right way ;) :D
04:20 karolherbst: it just let me reload the module without the need of a reboot
04:20 karolherbst: which is already a big win for me
04:20 karolherbst: yeah
04:20 karolherbst: thing is
04:20 karolherbst: the pmu gets the request, I am pretty sure of that
04:21 mupuf: oh, and about debugging, use the scratch registers :)
04:21 karolherbst: I used the pdaemon counter count regs now
04:21 karolherbst: :D
04:21 mupuf: LOL
04:21 karolherbst: there are more of them and I don't mess up other stuff :D
04:21 mupuf: well, that's a way, but the scractch regs are sort of for this :p
04:22 karolherbst: thing is, pmu_intr isn't called when the stuff get lost
04:23 karolherbst: but I don't know where this function is called
04:23 karolherbst: mupuf: dmesg with debug=debug for the first lost interrupt: https://gist.github.com/karolherbst/76b608fc8745acceec2e
04:24 karolherbst: I added a few prints too
04:24 karolherbst: this is just 1000 lines before the reply lost message
04:24 mupuf: this is not going to help me
04:25 karolherbst: k
04:26 mupuf: mwk: hey, can I bother you a bit about the IRQs in fuc? I was wondering if IRQs were reentrant, as in, can we get an IRQ while handling an IRQ?
04:26 karolherbst: mupuf: what I was a bit worries about was, that sometimes a timeout of 50ms was too short for a reply, does it makes sense to have a higher one?
04:27 mupuf: I would say that if one bit already is asserted, we should not get the same IRQ again until we ACK it
04:29 mupuf: what we could do is disable IRQs, ACK the irq, handle everything we need to do, then re-enable IRQs again?
04:30 mupuf: this way, the bit is free to be re-set again while we do processing
04:30 mupuf: karolherbst: yes, much higher one please
04:30 mupuf: like 1s
04:33 karolherbst: mupuf: I have 500ms now
04:33 karolherbst: but I can also do 1s if you want :D
04:33 karolherbst: mupuf: I was also thinking about useing wait_event_hrtimeout instead of wait_event_timeout because it uses ktime_t instead of jiffies
04:33 mupuf: all the timers in nouveau are more like 10s, 500ms is definitely very short :D
04:34 karolherbst: okay
04:34 mupuf: use whatever you like, I have no preferences on this
04:34 karolherbst: okay
04:34 karolherbst: I don't want to have this value too big
04:35 karolherbst: because this can be happen whenever
04:35 karolherbst: and the user waiting too long for the screen to be refreshed, well
04:35 karolherbst: especially because we have multiple calls to the pmu while reclocking
04:36 karolherbst: anyway, with 500ms I hadn't any false alarm so far, so I think 1s should be fine
04:36 karolherbst: and only a handfull with 50ms out of thousends
04:36 mupuf: mwk: seems like the docs you wrote already tell me the answer: Both ieX bits are always cleared to 0 when entering an interrupt handler.
04:37 karolherbst: mupuf: is there anything else I have to do in the reply timed out case?
04:37 karolherbst: and would you use another error code instaed of EBUSY?
04:38 mupuf: EBUSY sounds about good
04:38 karolherbst: EIO?
04:41 mupuf: whaetever pleases you, I am trying to find a solution to the irq issue first
04:42 karolherbst: k
04:51 karolherbst: I think I will use ETIMEDOUT, because the function has "send" in its name and if it returns ETIMEDOUT it is somehow clear what happend
05:17 karolherbst: new version of the patch with recovery fallback when wait timedout, but there is a queued message: https://github.com/karolherbst/nouveau/commit/553870c5e7b9da9f4aa8a958e783d29ff37346d7
05:26 mupuf: karolherbst: https://github.com/karolherbst/nouveau/blob/bd1328b4a7868160263c88438f9bce795cda72ef/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc#L216 <-- I guess the issue is here
05:26 mupuf: wait, maybe not, let me read more code
05:29 mupuf: no, the host_recv function does the right thign
05:29 mupuf: can you check on the host side if the ring buffer you are writing to is not getting full?
05:36 mwk: mupuf: yeah, entering any interrupt clears both enables
05:37 mupuf: right
05:37 mwk: perhaps the logic is that you can reenable them after entry?
05:37 mupuf: when would one want to do that?
05:37 mupuf: :D
05:37 mwk: enable hipri interrupts in lowpri interrupt handler
05:38 mupuf: oh, right
05:55 karolherbst: mupuf: what ring buffer?
05:55 karolherbst: ohh you meant the PUT/GET thingies?
05:56 mupuf: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/pmu/base.c#n43
05:56 karolherbst: mupuf: okay, so with my patch I am able to reclock without any sleeps between the echos for an hour
05:56 karolherbst: without the driver crashing or anything
05:56 karolherbst: and with glxgears running with vsync disabled
05:57 mupuf: that sounds pretty nice :)
05:57 karolherbst: mupuf: mhh nouveua just doesn't get the interrupt
05:57 karolherbst: there is data in the data segment and everything
05:57 karolherbst: also the data we expect
05:58 karolherbst: it just waits on line http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/pmu/base.c#n81
05:58 karolherbst: until the reply is comming from the pmu
05:58 karolherbst: wich doesn't
05:58 mupuf: but is it because the pmu does not receive the message or because the IRQ gets lost?
05:58 mupuf: I would bet the first
05:58 karolherbst: the IRQ get lost I guess
05:58 karolherbst: the pmu handles our request
05:58 mupuf: for sure?
05:58 karolherbst: look at my patch: https://github.com/karolherbst/nouveau/commit/553870c5e7b9da9f4aa8a958e783d29ff37346d7
05:58 karolherbst: this _works_
05:59 karolherbst: I just read out the reply without getting an interrupt
05:59 karolherbst: on timeout
05:59 mupuf: hmm, I see
05:59 mupuf: very good
06:00 mupuf: so, our interrupt handler on the nouveau side may be faulty then
06:00 karolherbst: mhh
06:01 karolherbst: could be, maybe not
06:01 karolherbst: how is nvkm_pmu_intr called?
06:01 karolherbst: because nvkm_pmu_intr doesn'T get called at all so it get lost somewhere earlier
06:03 karolherbst: mupuf: what do you think about returning an error even if we were able to retrieve data after a timeout? I was thinking that this is a nice way to let the user know something odd happend, so that the consumer can validate the data somehow
06:03 karolherbst: not sure about it though
06:04 mupuf: hmm, no need for the error code in this case
06:04 mupuf: I would say that maybe two IRQs get coalesced into one
06:05 mupuf: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/pmu/base.c#n91 <-- how about you check that there are not multiple messages here?
06:05 mupuf: that seems to be the problem
06:08 RSpliet: mupuf: is the nvkm_warn triggered?
06:09 mupuf: no idea, ask karolherbst
06:15 karolherbst: RSpliet: nvkm_pmu_intr is _not_ called
06:15 karolherbst: so nvkm_pmu_recv can't be called, because the worker isn't triggered as well
06:16 karolherbst: with my patch dmesg looks like this: https://gist.github.com/karolherbst/bf4c63fd8588d78857b4
06:18 karolherbst: mupuf: okay, so I just assume the interrupt could lost somehow, but everything else is in a sane state?
06:18 karolherbst: *got
06:18 mupuf: karolherbst: if two irqs get coaslesced, you will get one but two messages to read
06:18 mupuf: do you get what I mean?
06:18 karolherbst: ohh okay
06:18 karolherbst: yeah
06:19 mupuf: the pmu code does the right thing and loops
06:19 karolherbst: but this is already handled
06:19 mupuf: where>
06:19 mupuf: ?
06:19 karolherbst: at least I thought it would
06:20 karolherbst: maybe I saw some fuc code where something like that was done...
06:20 karolherbst: okay, I was wrong
06:21 karolherbst: mupuf: so if we would like always wait on a reply, could this still happen?
06:24 mupuf: not sure what you mean
06:26 mupuf: basically, what you need to do is to have a while (true) loop and return only when GET == PUT
06:26 karolherbst: mhh I am thinking about how two IRQs can happen at all, because there is only one request made for every nvkm_pmu_send :/
06:27 karolherbst: I can check that though
06:27 mupuf: ok, let's imagine that the cpu takes a lot of time to handle the IRQ, the pmu may send another one but it will get coalesced
06:28 mupuf: this can happen if you disable IRQs for some time I guess
06:28 mupuf: I mean, there must be reasons for it to happen
06:28 karolherbst: yeah, okay, but I don't see how this can happen in the nouveau code
06:28 mupuf: please test with the while loop and see if it fixes the issue
06:28 karolherbst: yeah
06:28 karolherbst: I will test that
06:28 mupuf: we are talking about hw and the rest of the kernel disabling irqs
06:29 mupuf: to be honest, I would need to read up again on the behaviour of x86 and the kernel
06:30 mupuf: but since the kernel can disable IRQs and there are no queuing mechanisms for IRQs, then this may happen
06:31 karolherbst: nope, still happens
06:32 karolherbst: checking if my change is actually right first
06:33 karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/cf35c99cdc8034658426cacb6ecc5a270eb7a98c
06:33 mupuf: the end of the loop should be after the warn
06:35 mupuf: why do you use schedule work?
06:35 mupuf: that is likely your bug
06:35 mupuf: https://github.com/karolherbst/nouveau/blob/cf35c99cdc8034658426cacb6ecc5a270eb7a98c/drm/nouveau/nvkm/subdev/pmu/base.c#L173 --> why don't you call the code straight away?
06:35 karolherbst: ohh this is just leftover before I noticed the IRQ get's lost
06:36 karolherbst: *gets
06:36 karolherbst: also
06:36 karolherbst: there was a deadlock when just calling it
06:36 mupuf: wait a sec
06:37 mupuf: no, this is good. you definitely do not want to be synchronous with the reception of a message
06:37 karolherbst: yeah
06:37 karolherbst: this tirggered some nvkm_pmu_sends because of memory reclocking and messed up everything
06:38 karolherbst: anyway, even with the loop end moved down, I still trigger the interrupt lost branch
06:38 mupuf: yop
06:39 karolherbst: mupuf: do you know how nvkm_pmu_intr get's called?
06:39 karolherbst: I fear it is somewhere deep inside the kernel
06:40 mupuf: sure, the root is the interrupt controller code in linux
06:40 karolherbst: maybe it would make sense to turn on some debug messages there
06:41 mupuf: well
06:43 mupuf: can you try disabling MSI interrupts?
06:43 karolherbst: how?
06:46 mupuf: http://nouveau.freedesktop.org/wiki/KernelModuleParameters/
06:47 mupuf: nouveau.config="NvMSI=0" ?
06:48 karolherbst: how can I verify that msi isn't enabled?
06:50 karolherbst: mupuf: mhh, the IRQ still get's lost
06:50 mupuf: you should be able to use the nouveau.debug to get information about the PCI subsystem
06:51 mupuf: as for msi, it was a long shot
06:51 mupuf: sauna time, will think about it there
06:51 mupuf: I will work on collecting the power usage from env_dump to prepare the work for the power/perf bench suite
07:36 hakzsam: imirkin, no piglit regressions with that nv50 compute support
07:43 imirkin: hakzsam: great :)
07:43 imirkin: hakzsam: did you run that with HUD or something else which would trigger the regressions?
07:43 imirkin: oh, i guess hud would mess it up =/
07:44 hakzsam: imirkin, no, I just checked that the init part of the compute support didn't break anything
07:45 imirkin: hakzsam: reasonable enough
08:11 pmoreau: `get_local_size()` working on NV50! Well, that was a really easy one, even way easier than `get_local_id()`.
08:13 imirkin: pmoreau: now try if () :p
08:14 pmoreau: :-D
08:14 pmoreau: No, first I'll check if they work on Fermi+, and get hello_world to work on Fermi+ as well
08:14 pmoreau: BTW, I got the joinat to work. :-)
08:15 pmoreau: But, still some troubles with the optimiser which doesn't optimise any of the branches, even though the conditions can be computed at compile time.
08:15 pmoreau: I'll probably investigate that before trying `if ()`
08:16 pmoreau: And I'll most likely submit `get_local_id()` and `get_local_size()` for review, as they do not depend on SPIR-V or TGSI, but can be used by both.
09:15 karolherbst: mupuf: I think we also need some kind of lookup functions for cstate => pstate translation, because not all cstates are available in all pstates
09:15 karolherbst: or is there something like that already?
09:27 karolherbst: mhh I know, 80 width... :/
09:28 mupuf: no idea if this exists
09:29 imirkin: pmoreau: it's entirely likely that we suck at removing conditional execution
09:29 karolherbst: mupuf: kernel code guide lines
09:29 karolherbst: mupuf: also tab is 8 spaces
09:29 karolherbst: :D
09:29 imirkin: pmoreau: or there's some bit of constant folding that could be added to become smarter at it... send me a sample program and i can see if there's an obvious reason
09:30 imirkin: karolherbst: 80 width is good. learn to like it.
09:30 imirkin: :p
09:30 karolherbst: :O
09:30 karolherbst: I don't care much about those 80 width
09:30 karolherbst: I dislike this tab == 8 more
09:30 karolherbst: this cuts a lot of the width :/
09:31 imirkin: yeah, i'm not big on using tabs either.
09:31 imirkin: my personal preference is 2-space indent
09:31 pmoreau: imirkin: I'll send you a sample program, so you can check if it's my fault or not. But, I think I'd like to give it a try to solve the issue, except if you want to do it. :-)
09:31 imirkin: pmoreau: well, i wouldn't spend any time on it... just a glance to see if i see an obvious problem or not
09:31 pmoreau: +1 for 2-space indent :-)
09:31 imirkin: pmoreau: happy to let you do it all.
09:31 pmoreau: ;-)
09:32 karolherbst: imirkin: For me 2 is a bit too small
09:32 karolherbst: and I like using tabs instead of spaces
09:32 karolherbst: because
09:32 karolherbst: the viewer can decide how big a tab is :p
09:33 imirkin: not really
09:33 imirkin: unless you're *super* careful about when to use tabs vs spaces
09:33 imirkin: i'm not aware of any editor that is
09:33 karolherbst: well it is easy: tabs until block indent
09:33 karolherbst: space to fill up
09:33 karolherbst: or tab if the position doesn't matter
09:33 imirkin: like if you have e.g.
09:33 karolherbst: space when position matters
09:33 imirkin: <a bunch of block indent>foo = barsdlkjjsdflkjdsflkjd(more args
09:34 imirkin: and then you indent the next line to the (
09:34 karolherbst: ^ yeah, covered by the stuff I said
09:34 imirkin: you don't want to do it with tabs
09:34 imirkin: well, at least emacs doesn't handle that afaik
09:34 karolherbst: nobody really does
09:34 karolherbst: but it is the sanest approach
09:34 imirkin: sure
09:34 karolherbst: *saniest? :D
09:34 karolherbst: no idea
09:34 imirkin: sanest.
09:34 pmoreau: If you're going to put spaces if position matters, why not use spaces all the time?
09:34 karolherbst: k
09:35 karolherbst: pmoreau: because you can use tabs until it doesn't matter
09:35 pmoreau: s/if/when
09:35 karolherbst: like if you are in a block
09:35 karolherbst: you can use tabs until you reach the block indentation
09:36 karolherbst: pmoreau: my idea is, that you should use tabs and spaces in a way, it looks good for everyone
09:36 karolherbst: and where the width of tabs is configurable
09:36 karolherbst: if you use spaces, the viewer can't change the width really
09:37 pmoreau: Right, but I can't see how you can keep a coherent view with both spaces and tabs
09:37 karolherbst: it is possible
09:37 imirkin: pmoreau: what karolherbst said... use tabs for block, spaces for alignment
09:37 pmoreau: If you use spaces for a line, due to specific position, then the whole block and up have to use spaces as well, to keep the alignment
09:38 imirkin: but due to invisible nature of it all, people will *invariably* screw up
09:38 imirkin: therefore tab == 8 spaces. that's pretty much the only valid interpretation.
09:41 pmoreau: karolherbst: So, in this examples, where would you put tabs and where space? https://phabricator.pmoreau.org/P62
09:41 pmoreau: s/examples/example
09:41 karolherbst: pmoreau: " 2);"two tabs, fillup with spaces
09:41 pmoreau: Oh wait, I think I got it
09:41 karolherbst: :D
09:42 pmoreau: I thought you would put spaces for the whole line
09:42 karolherbst: nooo
09:42 pmoreau: Now I get it
09:44 karolherbst: imirkin: I think most of the people screw this up, because no editor can get this right for whatever reason
09:44 imirkin: yeah, so just sticking to spaces is the simplest policy ;)
09:45 pmoreau: I guess you could enforce that using clang_format
09:45 pmoreau: Or some similar tool
09:46 imirkin: i've never seen such a tool work perfectly
09:53 karolherbst: me neither
10:12 karolherbst: does this looks cleaner than the previous version? https://github.com/karolherbst/nouveau/commit/03092aef18c6b877c922e9f34246fc1dda8b87f7
10:39 karolherbst: mhhh, the rcu code doesn't even honor the width, so maybe it really doesn't matter that much
10:48 karolherbst: mupuf: super stress test: having my dyn reclock code on the pmu send reclocks request, while playing a game through wine and cating my current_load interface file, which asks the pmu every time, while havving a loop changing pstates between 07/0f without sleeps in between :)
10:48 karolherbst: seems to work
10:49 karolherbst: dmesg looks nice though
10:49 karolherbst: uhhh it messed up big time
10:49 karolherbst: "hpet1: lost 1 rtc interrupts"
10:50 karolherbst: [drm:fw_domains_get] *ERROR* render: timed out waiting for forcewake ack request.
10:50 karolherbst: https://gist.github.com/karolherbst/914d84c61bb47646598d
10:54 karolherbst: okay, the gpu crashed
10:55 karolherbst: okay
10:56 karolherbst: we shouldn't read a reg in a while loop until it changes :/
10:56 karolherbst: the kworker threads loops here: https://github.com/karolherbst/nouveau/blob/master_karol_no_touchy/drm/nouveau/nvkm/subdev/pmu/base.c#L111
10:56 karolherbst: and because the gpu crashed, I get bad0011f all the time
10:57 karolherbst: yeah, we want to use something with nvkm_msec thre
11:42 karolherbst: imirkin: your suggestions were good, I start to like my patch myself now
11:42 imirkin: hehe
11:45 karolherbst: if (stuff != other_stuff) { more_stuff... } else return; havin else { return }, isn't the proper fix here ;)
11:46 karolherbst: ayway, v3 looks much cleaner now and I think good enough now
11:47 imirkin: cool
11:47 karolherbst: ohh my other patch has also an issue.. meh :/
11:51 karolherbst: enough patches for today
13:15 pmoreau: imirkin: Here you go for the sample: https://phabricator.pmoreau.org/P63 is the NV50 IR code, and https://phabricator.pmoreau.org/P64 the 255 debug output :-)
13:17 imirkin: pmoreau: just add OP_SET handling to ConstantFolding::expr(Instruction *i,
13:17 imirkin: ImmediateValue &imm0, ImmediateValue &imm1
13:21 pmoreau: Ok, will try to add that :-)
13:23 imirkin: there may be more to it, but it's a start
13:41 pmoreau: There is more to it, as it doesn't like to move to a flag
13:41 pmoreau: But, it is a good starting point. :-)
13:42 pmoreau: Oh! The assert might need to be updated. :D
13:47 imirkin: yeah, figured that might be an issue
13:48 imirkin: but if it's trying to move into a flag, you've already failed
13:49 pmoreau: Hum… For the OP_SET, I went with setting the res.data to the comparison result
13:50 imirkin: that's right
13:50 imirkin: but if you're ending up with like mov $c0 $r1
13:50 pmoreau: So I need to add something more to avoid getting a mov later on
13:50 imirkin: or some immediate
13:50 imirkin: that means you still use that condition
13:53 pmoreau: Yeah right, it only replaced the "mov u32 %r1 0x00000002; mov u32 %r4 0x00000000; set u32 %r3 ne %r1 %r4" with a "mov u8 $c0 - 0x0000000000000001", but kept the remaining
14:30 imirkin: hakzsam: that trace you sent earlier should decode fine now
14:40 hakzsam: imirkin, yep, it's nice, thanks!
14:41 imirkin: the $r124's are 0's btw
14:41 hakzsam: okay
14:41 imirkin: in case you were wondering :)
14:42 imirkin: since immediates can't be used in most places, but high registers are auto-initialized to 0
14:42 imirkin: we use $r63 sometimes too... since having small register numbers allows you to use a shorter encoding
14:43 RSpliet: imirkin: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f94e1d97381ec787c2abbbcd5265252596217e33 I get the feeling that this does the exact opposite of what the commit msg implies...?
14:44 imirkin: RSpliet: what makes you feel that way?
14:44 RSpliet: ehehehe
14:44 RSpliet: incompetence
14:44 RSpliet: green always was "removed line", right?
14:45 imirkin: :p
15:09 imirkin: hakzsam: btw, you might consider an op like "set $c0 # e u16 $r0l $r1l"
15:09 imirkin: [for nv50_read_hw_sm_counters_code]
15:10 imirkin: hakzsam: you might also consider a refactor that moves all that code out to separate files that are then built with envyas... look at nvc0/mme and codegen/lib
15:27 pmoreau: imirkin: What is the point of having both cc and setCond for an instruction?
15:28 imirkin: the more the merrier? i forget :)
15:28 pmoreau: :D
15:28 imirkin: one has to do with random ops setting $c
15:28 imirkin: the other has to do with set
15:28 imirkin: or cc might have to do with carry? i really don't remember :)
15:29 pmoreau: I was looking at cc to switch on the CondCode and do the correct operation in expr, but it was always CC_TR, even if I never set it to that value
15:29 imirkin: errrr
15:29 imirkin: ok i'm going ot have to look now :p
15:30 imirkin: ok, so setCond is on a CmpInstruction
15:30 imirkin: and it's the condition used for the set instruction
15:30 imirkin: so like le/gt/etc
15:30 pmoreau: Right
15:30 imirkin: give me a min for 'cc'
15:30 pmoreau: Sure, no hurry :-)
15:31 imirkin: right. cc is for predicated execution
15:31 imirkin: so like (lg $c0) mov foo, bar
15:31 imirkin: that lg comes from cc
15:32 pmoreau: Hum… And I guess you can have `(lg $c0) set $c1`?
15:32 imirkin: dunno about nv50, definitely on nvc0
15:32 pmoreau: Ok
15:32 imirkin: (but with predicates)
15:32 imirkin: and they're logically very different things
15:33 imirkin: even if they were mutually exclusive, which they're not
15:33 pmoreau: That's true! :-)
15:34 imirkin: perhasp you need to replace the OP_SET with another OP_SET that has a setCond set to CC_TR/CC_FL?
15:34 imirkin: note that OP_SET can set both flags and regs
15:35 imirkin: e.g. you can do set $r0 eq $r1 $r2
15:35 imirkin: which will set it to a 0/-1 value
15:35 pmoreau: That could be a way to do it I guess
15:35 imirkin: (and on nvc0 you can also have a "bool float" flag which will set it to 0.0/1.0)
15:36 pmoreau: CC_LTU, CC_xyU are for unsigned, right?
15:55 imirkin: pmoreau: tbh, i'm not sure. maybe?
15:56 imirkin: look at what nv50_ir_from_tgsi does and assume it's right :)
15:57 pmoreau: For now I'm just hardcoding to compare the u32 values of a->data an b->data, as it is what I have.
15:57 pmoreau: When I get to successfuly remove the unnecessary branches, I'll get back to it.
15:57 imirkin: i think the *U variants are something else. don't know what though.
15:58 imirkin: probably mwk does
15:59 imirkin: pmoreau: you can see if perhaps nvdisasm is more verbose on the matter
16:00 pmoreau: I'll give it a try
16:38 mwk: pmoreau: U means unordered
16:38 mwk: which is important when comparing floats
16:39 mwk: and doesn't matter for ints
16:39 pmoreau: mwk: What is unordered in that case?
16:39 mwk: pmoreau: NaNs
16:40 mwk: never heard of them? you must be a happy person...
16:40 pmoreau: Ok
16:41 pmoreau: I did hear about NaNs :D
16:41 imirkin: mwk: what if i stuck fingers in my ears as the other person was saying it... do i count as happy? :)
16:44 mwk: I suppose... the other person, not so much
16:51 imirkin: mwk: so "U" means "i don't care about NaN-related ordering"?
16:54 mwk: uh? no
16:55 mwk: there are 4 possible results of a float comparison: less than, equal, greater than, unordered
16:55 mwk: and the condition name is a mask of which conditions should be tested for
16:56 mwk: so "lg" branches if comparison result was "lesser" or "greater"; "lgu" branches if it was "lesser", "greater", or "unordered"
16:57 imirkin: ahh i see
16:57 imirkin: and "NEU" = not (equal || unordered) ?
16:58 mwk: heh.
16:58 mwk: I avoided using shortcut names for exactly this reason
16:58 mwk: no idea
16:59 mwk: but I'd guess it'd be lgu
17:00 mwk: yep, seems to be lgu
17:00 imirkin: so it's really "not equal"?
17:00 mwk: yeah. annoying, isn't it...
17:00 imirkin: i won't dare ask what NE is :)
17:01 imirkin: is it lg?
17:01 mwk: yeah
17:01 imirkin: excellent.
17:01 imirkin: ok, so U is assumed to never be there
17:01 mwk: which, incidentally, is not what != does on floats
17:05 imirkin: unless explicitly specified
17:07 imirkin: != is lg right?
17:07 imirkin: or is it lgu?
17:08 mwk: != should get you lgu
17:08 mwk: since NaNs are supposedly not equal to anything, including other NaNs
17:08 mwk: all other C operators correspond to non-u versions
17:09 imirkin: right
20:31 AssOfZelda: Year 2002 / 2003, NV1F celcius GeForce4 MX IGP has severely distorted opengl rendering. is that normal with nouveau or solvable ?
20:44 imirkin: AssOfZelda: what version of mesa, and what do you mean by 'distorted'?
20:50 imirkin: AssOfZelda: i made a *significant* fix to it in mesa 10.3, and a few small additional fixes over the last few releases... outside of a few small things, the driver should basically work.
20:54 exidux: Bad nickname...
20:54 imirkin: the biggest things that don't work but ought to are 3d textures and glClipPlane
20:55 imirkin: these are just not supported by the hw
20:55 imirkin: the clip plane thing has a clever workaround possible, afaik 3d textures just have to fall back to swrast
20:55 exidux: mesa 11.0.5-1 arch linux package*
20:55 imirkin: ok, that's pretty recent
20:55 imirkin: take an apitrace of the application in question, make sure that you see the same issues on replay
20:56 imirkin: and file a bug with the trace along with a screenshot
20:56 imirkin: at bugs.freedesktop.org Mesa -> DRI/nouveau (i think)
20:56 imirkin: apitrace = http://github.com/apitrace/apitrace
20:56 exidux: i will take a look at that.
20:57 exidux: cant expect to much though from such an extremely old card.
20:57 imirkin: well, you just get GL 1.2 with it (+ extensions)
20:57 imirkin: but they should largely work
20:58 exidux: everything non desktop program using opengl for 2D is causing severe ghosting effects and digital artifacts.
20:58 imirkin: exidux: oh, also check to see if there are any errors in dmesg, that could be indicative of various issues
20:58 exidux: ^
20:58 imirkin: when you say ghosting you mean... misrender?
20:58 imirkin: or do you mean an analog ghosting effect?
20:59 imirkin: iirc there was someone talking specifically about NV1F's having some sort of analog-seeming issues
20:59 exidux: i mean misrendering, double images, glitched, etc.
20:59 imirkin: fwiw this is the bug: https://bugs.freedesktop.org/show_bug.cgi?id=54587
20:59 imirkin: sounds like you have something else though
21:00 imirkin: er hm, now that i look at those screenshots, might be the same thing
21:02 exidux: yeah it resembles that only more like a broken DVD at times and nt on xfce desktop. it begins whenever programs begin to use opengl though.
21:03 imirkin: is the whole screen messed up
21:03 imirkin: or just the application in question?
21:04 exidux: boots seemingly ok. open an extra appplication which uses opengl, artifacts, close app, desktop begins to glitch, everything downhill.
21:04 imirkin: hmmmm sounds like the same issue then :(
21:04 exidux: disabling compositing changes nothing. whenevr-
21:04 exidux: whenever something extra hops onto the opngl train it begins.
21:04 imirkin: i'm as perplexed now as i was then
21:05 imirkin: esp when that guy commented that hd activity made things worse
21:05 imirkin: we're probably not initializing something, but who knows what...
21:05 exidux: the IGP uses system memory though.
21:06 imirkin: yep...
21:06 imirkin: plenty of other things to not initialize :)
21:06 exidux: already used kernel param mem=896mb to free up +200mb for the chip to test.
21:06 imirkin: errrr wha?
21:06 imirkin: it should create a memory hole in the bios
21:06 exidux: Yeah but i was testing "more" lol
21:07 exidux: extra tests*
21:08 imirkin: so... it's unlikely that there's actually determinstic misrendering... it's more of a system issue. and sadly i have no idea what it might be. sorry!
21:09 exidux: no problem
21:09 imirkin: if you wanted to investigate, you could look at the mmiotrace the other dude made and try to compare it to what nouveau is doing, and try to poke random things until it magically starts working
21:09 exidux: this stuf is ancient anyways.
21:10 exidux: i will look into it and see if i can handle it. XD
21:10 imirkin: without the hw, it's a bit futile, since there's millions of things that we do differently, and there's no way to know, without the hw, that this reg write is "it"
21:10 imirkin: which is why i haven't looked at it
21:13 imirkin: exidux: one random thing to try which probably won't help but who knows -- boot with nouveau.config=NvForcePost=1
21:13 exidux: will test.
21:14 exidux: dont get why nvidia doesnt release a map, headers, partial sources or something from their unsported legacy line :/
21:14 imirkin: because it's easier not to?
21:15 imirkin: you could also try using xf86-video-nv instead of nouveau
21:15 imirkin: i should actually see if that had any funny business for NV1F
21:16 imirkin: hmmmm
21:17 imirkin: this is the most disgusting code ever
21:18 imirkin: looks like something special done for nv1a and nv1f for mode calculations...
21:28 imirkin: exidux: hmmm... noticed at least one apparent problem!
21:28 exidux: heh.
21:29 imirkin: exidux: in nouveau_hw_get_clock, it takes the NFORCE2 case. make that say "return clock / 1000"
21:29 imirkin: [dunno how familiar you are with modifying code... if you're not, let me know]
21:31 exidux: lets see if i can get it set up , the achine is not connected to the net :3
21:31 imirkin: exidux: drivers/gpu/drm/nouveau/dispnv04/hw.c
21:32 exidux: ok ill make a memo on the machine and will try to get the needed files over there.
21:33 imirkin: skeggsb: i'm comparing the logic between nouveau_hw_get_clock and nForceUpdateArbitrationSettings
21:33 imirkin: skeggsb: looks like we forget to divide by 1000 in the 0x1f case and to shift the postdiv by 256
21:33 imirkin: er, shift by 8 :)
21:34 imirkin: skeggsb: that code is about as clear as molasses... so... i could be missing something
21:40 imirkin: skeggsb: also nv10_calc_arb seems *way* simpler than nv10CalcArbitration...
21:40 imirkin: skeggsb: seems like that function needs to gain back the !video_enable case at least
21:53 exidux: -.- ah. i should have downloaded the out of tree version... compiling a full kernel would take a bit to long -.-
22:11 exidux: going to check if i have eveything set up... i hate doing usb storage based transfers -.-