00:28 mwk: ha, found a new v5 opcode
00:28 mwk: 0xf3 <imm16> is apparently a 16-bit pc-relative call
00:28 mwk: not sure about the "pc-relative" part yet...
00:59 mwk: alright guys
00:59 mwk: who reversed the "mpop*" Falcon v5 crap?
01:07 mwk: it's batshit crazy in many interesting ways
01:11 mwk: anyhow
01:11 mwk: apparently, the invalid opcode trap no longer exists on v5
01:12 mwk: because there are no more invalid opcodes
01:14 mupuf: mwk: no more invalid opcodes :o?
01:15 mupuf: they achieved 100% utilisation of the opcode space? :D
01:15 mupuf: or they got rid of this useless trap feature that was wasting silicon?
01:15 mwk: not exactly
01:16 mwk: but 100% of the opcode space is covered by valid forms
01:16 mwk: so the processor always knows how many bytes to fetch and how to decode the opcode
01:16 mwk: but, in some of these forms, there are unassigned subopcodes
01:17 mwk: which will usually just set the destination register to 0, and maybe some flags as well
01:18 mupuf: I see
01:47 mwk: karolherbst: how do you wait for a pause?
02:56 Horizon_brave: hey everyone
04:02 Lemmata: Hello! It looks like I'm getting soft CPU lockups which render my system unusable, Most likely due to nouveau as when I black list nouveau in /etc/modprobe.d the lockups stop and I am able to startup my computer normally. Can anyone help me out on diagnosing the issue and potentially filing a bug report?
06:15 jayhost: 2D/3D acceleration supported on all GPUs". Woah
07:58 karolherbst: mwk: the heck?
07:59 karolherbst: mwk: maybe just a hardware bug?
08:00 karolherbst: mwk: what do you mean by waiting for a pause?
08:39 mwk: karolherbst: the div thing?
08:39 karolherbst: yeah
08:40 mwk: it turns out to be my bug actually, sort of
08:40 karolherbst: ohh, I see
08:40 mwk: %r0 is the first register I read back from the Falcon
08:40 mwk: and div is a long instruction, it doesn't have time to complete before I read the reg
08:41 mwk: which is why I asked how you wait for the Falcon to pause after single-stepping
08:42 mwk: or, for that matter, how you know when a breakpoint was hit
08:42 mwk: in related news
08:43 mwk: I'm trying to add the 6 status registers to hwtest as well
08:44 mwk: without much success so far
08:44 mwk: though I did nail down a few bits
08:45 mwk: status #1 reveals some bits of Falcon's inner workings
08:45 karolherbst: I don't wait, because I single step by hand
08:45 karolherbst: usually the result is already there
08:45 karolherbst: so I never see the opposite
08:45 karolherbst: *saw
08:45 karolherbst: and I also don't get notified on a hit breakpoint
08:46 karolherbst: I can read out the $pc though
08:46 mwk: not good...
08:47 mwk: I single step by hand as well
08:47 karolherbst: well, currently I am mainly toying around with my script
08:47 karolherbst: which automates tons of stuff
08:47 mwk: and I'm having problems with division
08:47 karolherbst: like reading out the $pc, parsing the code and so on
08:47 karolherbst: mhhh
08:47 mwk: I suppose there's something you need to monitor to figure out if shit is done already
08:48 karolherbst: maybe
08:48 karolherbst: but I checked some div instructions as well
08:48 karolherbst: and when the $pc moves to the next instruction, the last div was already executed
08:48 mwk: maybe your debugger is just slower :p
08:48 karolherbst: well I didn't check like immediatly
08:48 karolherbst: maybe
08:48 karolherbst: it's a script I invoke by hand
08:48 mwk: weren't you writing it in bash?
08:48 karolherbst: yeah
08:49 mwk: well, that explains things
08:49 karolherbst: https://github.com/karolherbst/nouveau_tools/blob/master/dbg_falcon.sh
08:49 mwk: I supppse by the time Linux starts a new process, Falcon can manage to perform one division :p
08:49 mwk: I kind of hit registers as fast as possible in C++
08:50 karolherbst: yeah, I still plan to write one in C/C++ with nice cli interface and everything
08:50 karolherbst: currently just mainly toying around
08:50 mwk: let's hope we figure out the required waits before that
08:50 mwk: anyhow, status register #1 is interesting
08:51 mwk: it appears to have a list of pending register writes for long-running instructions
08:51 karolherbst: interesting
08:51 mwk: eg. it says "someone is supposed to write 16-bits to %r7, and 32 bits to %r1"
08:52 mwk: AFAICT, mulu/muls, div/mod, ld are considered long-running
08:52 karolherbst: mhh
08:52 mwk: probably iord as well, but I don't test that instruction at the moment
08:52 karolherbst: never had any problems with ld to be honest
08:52 mwk: wait until you write your debugger in C :p
08:53 karolherbst: what does long running mean anyhow? 2-4 cycles? or is there something taking even longer?
08:53 mwk: *shrug*
08:53 karolherbst: I meant, it was never a problem in the code I wrote for the PMU
08:53 karolherbst: or does the falcon wait on reads then?
08:53 mwk: it means it runs long enough that Falcon starts executing subsequent instructions
08:53 mwk: nah, of course it waits for reads
08:54 karolherbst: okay
08:54 mwk: the whole point of this reg seems to be listing registers that you need to wait on
08:54 karolherbst: do you mean 0x4c?
08:55 karolherbst: or STATUS_READ in 0x200?
08:55 mwk: I suppose all non-long-running instructions are so fast that the results are available immediately
08:55 mwk: STATUS_READ
08:55 karolherbst: k
08:55 mwk: there are 6 different status registers
08:55 karolherbst: ohhh, I see
08:55 mwk: you pass the index in 0x200, like you do for normal registers
08:55 mwk: and you can read things
08:55 karolherbst: yeah, I know
08:55 karolherbst: I do it for registers already
08:56 mwk: it seems that status register 3 is what was 0x128 on Falcon v3, but with a few bits moved around
08:56 mwk: status register 1 appears to be for long-running instructions, and their register writes in particular
08:57 mwk: status 0 contains what I believe are the "interrupt 0 pending" and "interrupt 1 pending" bits
08:57 mwk: plus something about trap handling, I think
08:57 mwk: status register 4 can be used to read back the break mask
08:57 mwk: and that's all I know so far
08:58 karolherbst: nice
08:58 karolherbst: 4 seems to be handly
08:58 karolherbst: *handy
08:58 karolherbst: something a debugger needs
08:58 mwk: eh
08:59 karolherbst: (or it could just save it itself)
08:59 mwk: the break mask is something you stored yourself :p
08:59 mwk: but sure
08:59 karolherbst: mhhh
08:59 karolherbst: write ffff
08:59 karolherbst: read back
08:59 mwk: the break mask is in bits 16-31 of the register if you need it
08:59 karolherbst: you know valid bits -> profit
08:59 mwk: yeah well
08:59 mwk: valid bits are ffff
08:59 karolherbst: :D
08:59 karolherbst: what a surprise
08:59 karolherbst: and we know 3 for sure of those
08:59 mwk: doesn't mean all are used
08:59 mwk: 4
09:00 karolherbst: which one as well?
09:00 mwk: bit 5 is TLB_MISS
09:00 karolherbst: okay
09:00 karolherbst: adjust falcon.xml :p
09:00 mwk: though I cannot get single-stepping traps to work no matter what I do
09:00 karolherbst: yeah, I somehow failed to get the traps working as well
09:00 karolherbst: reading back 0x100 is helpful
09:00 karolherbst: if something went wrong, it prints out STOPPED
09:01 karolherbst: basically means the falcon gave up
09:01 karolherbst: *meaning
09:01 karolherbst: the same with breakpoints
09:01 mwk: I just know that bit 5 in the break mask makes TLB miss trap do different things :p
09:01 karolherbst: if you set a breakpoint, but not break on it in the break mask
09:01 karolherbst: the falcon stops
09:01 mwk: not exactly true
09:01 mwk: Falcon starts executing the usual trap handler at that point
09:01 karolherbst: okay, sure
09:02 karolherbst: but then the falcon doesn't halt
09:02 karolherbst: and it's quite useless from a debugger point of view
09:02 karolherbst: mhhhhhhhhhhh
09:02 karolherbst: mwk: I am wondering
09:02 karolherbst: mwk: maybe bit 7 isn't BREAKPOINT, but TRAP?
09:04 mwk: unless it already has $ta set in $flags, in which ccaase, bye
09:04 karolherbst: well, bits 0-6 and 10-31 aren't for traps for sure
09:04 karolherbst: and 8 and 9 are iv0 and iv1
09:05 karolherbst: mwk: I can only check it in like 8 hours, do you want to check if bit 7 in the break mask is more generic and includes _any_ trap?
09:06 mwk: no
09:07 mwk: I already told you, bit 5 is the TLB_MISS trap
09:07 mwk: so 7 definitely doesn't cover all traps
09:07 karolherbst: okay, then it may cover a few traps
09:07 mwk: doubtful
09:07 karolherbst: maybe even the sw traps 0-3
09:07 mwk: if TLB miss is separate, I suppose they all are
09:07 karolherbst: not traps 0-3
09:07 mwk: except maybe individual sw traps
09:07 karolherbst: yeah
09:08 mwk: eh.
09:08 mwk: I will check TLB multi hit and sw traps soon
09:08 mwk: I cannot check invalid opcode on this hwtest though
09:08 mwk: stupid v5 and its fully covered opcode space
09:08 karolherbst: :/
09:08 mwk: I mean, "covered"
09:09 karolherbst: well I can also check the sw traps, because I have the code for this already
09:16 karolherbst: mwk: I think the invalid opcode may also be bit 7, because it wasn't any of the other ones afaik.
09:16 karolherbst: or maybe I did something terribly wrong
10:05 mwk: hmm
10:06 mwk: NFI what that's about, but $cauth bit 19 affects trap semantics *somehow*
10:06 mwk: as in, it determines if bit 22 of status reg 0 is set after a software trap
10:06 mwk: whatever the fuck that is
10:06 karolherbst: mhhh
10:06 karolherbst: it also affects interrupts
10:07 karolherbst: I have ideas
10:08 karolherbst: do you know what bit 22 is?
10:08 mwk: NFI
10:08 mwk: I just know it's set on sw trap iff $cauth bit 19 is clear
10:10 karolherbst: mhh
10:11 karolherbst: I totally forgot what bit 1 was
10:11 karolherbst: ohh wit
10:11 karolherbst: *wait
10:11 karolherbst: I remembered
10:13 karolherbst: mwk: so bit 8-23 are configuration bits? I guess you don'T really know what those are about?
10:13 mwk: of #cauth?
10:14 mwk: bits 16, 17, 19 are some sort of flag bits
10:14 mwk: 0-8 is base address, 24-31 is size, rest are unused
10:14 karolherbst: yeah, I know the address bits
10:14 karolherbst: ohh, okay
10:14 mwk: bit 16 controls code xfers
10:15 mwk: if it's set, xcld'd pages will be marked as secretful
10:15 karolherbst: 8 is part of base address?
10:15 karolherbst: weird
10:15 mwk: and I have no idea about bits 17 and 19
10:15 mwk: well, maybe an idea about bit 19
10:15 mwk: it could perhaps be used to disable traps while in secure code?
10:16 karolherbst: maybe
10:16 mwk: hmm
10:16 karolherbst: but why though?
10:16 karolherbst: afaik interrupts get disabled automatically anyway
10:16 mwk: so breakpoints you set before secure entry won't fire?
10:16 karolherbst: or well, "reset" is the proper term I think
10:16 karolherbst: no clue
10:16 mwk: *shrug*
10:16 mwk: it definitely affects the sw traps somehow
10:17 mwk: we'll figure it out later, I suppose
10:17 karolherbst: yeah
10:20 mwk: alright
10:20 mwk: sort of confirmed
10:20 mwk: $cauth bit 19 is some kind of master interrupt/trap disable
10:21 karolherbst: how can you even confirm this?
10:22 mwk: status reg 0 bits 23 and 24 are "interrupt 0/1 pending", respectively
10:22 mwk: if I set $cauth bit 19, these are forced to 0
10:22 karolherbst: ahhhh
10:22 karolherbst: I see
10:23 mwk: also, the sw trap thing doesn't set bit 22
10:23 mwk: which I'm starting to think is a "trap pending" bit
10:23 mwk: I think sw traps are executed in two phases
10:24 mwk: the first single step you do steps $pc over the sw trap and writes $tstat register
10:24 mwk: and sets the "trap pending" bit
10:24 mwk: but then you need a second single step to actually enter the trap handler
10:25 karolherbst: yeah
10:25 karolherbst: this makes sense
10:25 mwk: ie. push old $pc, load $pc from T$tv, set $flags.tv etc.
10:25 mwk: probably all traps are executed in two phases like that, matter of fact
10:25 karolherbst: the falcon always halts at the instruction _after_ the trap
10:25 mwk: look at status reg 0
10:25 karolherbst: can't do it from here
10:26 mwk: bit 22 should be "a trap is pending instead of executing the next insn"
10:28 mwk: and uh
10:28 mwk: here comes strangeness
10:28 mwk: I think the "is interrupt X enabled" signal is delayed by one instruction or something like that
10:29 mwk: so eg. you could get an interrupt immediately after a "bclr $flags ieX" instruction
10:30 karolherbst: I doubt this
10:30 karolherbst: I think the hw needs a cycle to setup the interrupt handler/stuff
10:30 karolherbst: but then it fires those immediatly
10:31 mwk: well, there are the "interrupt pending" bits in stat 0
10:31 karolherbst: mhh
10:31 mwk: and they're based on $flags.ie* from *before* the last single-stepped instruction
10:31 karolherbst: yeah, that makes sense
10:31 karolherbst: ohh okay
10:31 karolherbst: yeah, makes sense
10:31 karolherbst: I saw this behaviour as well or at least it explains what I observed
10:41 RSpliet: hmm... I guess I'll get in trouble with DDX maintainers if I change the notation of ops in envydis to always include the return type
10:45 mwk: which ops?
10:45 RSpliet: stuff like imad (which is shown as e.g. add $r2 (mul s32 $r0 s32 c0[0x30]) $r5 - but doesn't explicitly state it does a signed addition)
10:46 mwk: uh... it doesn't?
10:46 mwk: addition doesn't really come in signed/unsigned variants
10:47 RSpliet: I thought it had some influence on how to calculate overflow flags...
10:47 mwk: nope
10:47 mwk: the overflow flag is always signed overflow, the carry flag is always unsigned "overflow"
10:48 RSpliet: hmm, convenient
10:50 RSpliet: still, my purpose is to quantify the ratio between mem ops/integer arith/fp arith/... so a more regular output format would help me regardless of whether the information is redundant. Guess I don't have to upstream that stuff really
10:50 mwk: weh
10:51 mwk: tbh having the type as an instruction modifiers was one of my bigger mistakes in envydis
10:51 mwk: it really should have been add vs fadd vs dadd, not add b32 / add f32 / add f64
10:52 RSpliet: would've been nicer to write asm that way I guess... but as a reader I don't mind either
11:05 karolherbst: sell it gets fun with instructions having seperate dType and sTyper
11:05 karolherbst: *sType
11:05 karolherbst: *well
11:08 mwk: here's what I know about status regs so far
11:10 RSpliet: mwk: I'm not sure if meh.c and nes.c exist
11:11 mwk: oh fuck me.
11:11 mwk: I knew I shouldn't do CTFs and production work in the same git clone...
11:13 karolherbst: mwk: https://github.com/envytools/envytools/commit/bdc84dc1b41b267c32eb9296c6e23dd25314927e#diff-c7ef2321ed59046ae536c78d8e91b6c8 and dis-intern.h
11:14 karolherbst: we should configure travis-ci to leave a message here on failed builds
11:15 mwk: yep...
11:19 karolherbst: it would be too easy travins being happy now
11:19 karolherbst: check_rnndb fails
11:20 karolherbst: I think I will mod the travis-ci file to 1. leave a message here and 2. printing out details about failing tests
15:37 smusiland: Allah is doing
15:38 smusiland: aaronp: abff aboll adsworth chithead specing
15:50 specing:launching drone...
15:54 RSpliet: Is it me who sucks at writing OpenCL kernels, or is the arithmetic in those things heavily dominated by integer operations? (like 60-80% of all ops)
15:54 RSpliet: sorry, 50-75% is a more accurate band
15:56 karolherbst: RSpliet: I think this is normal. Also OpenGL compute shaders contain more integer operations than any other
15:59 RSpliet: Yeah I bet it's the same for Cuda... just lots of pointer hymnastics
15:59 RSpliet: *gymnastics
16:00 RSpliet: I guess it all pans out nicely if int arith is a fraction of the cycles (throughput) of fp. If you dual-issue, you'll need about as many ALUs as FPUs (... but do they share hw? hmm...)
16:02 mupuf: RSpliet: are 32 bits ALU that big, area-wise, compared to an FPU?
16:02 RSpliet: mupuf: an FPU is, ignoring a lot of details, a wide ALU with preshift/postshift logic
16:03 RSpliet: multipliers are just big, whether FP or int
16:03 mupuf: ack
16:07 specing: multipliers can be small if you allow them to take word-size cycles
16:08 specing: basically shift + add
16:08 specing: they are only huge if you want them fast
16:10 mupuf: word-size cycles_
16:10 mupuf: ?*
16:11 karolherbst: 32 cycles for 32bit values?
16:11 karolherbst: I think
16:11 mupuf: ah! Right!
16:14 specing: yes
16:15 specing: it gets more complicated the faster you want it done
16:16 specing: so instead of 32 cycles you can have a reasonable trade-off at 4 or 8 cycles
16:16 specing: depends on application
16:16 karolherbst: is it even possible in one cycle?
16:16 specing: sure
16:17 specing: and you can do OoO execution where mul timing doesen't matter that much anymore (as long as mul time < average number_of_all_instructions/number_of_muls in a program)
16:18 specing: since other stuff can execute simultaneously
16:18 karolherbst: well sure, but I meant without OoO tricks and being able to do them one after each other infinitly
16:22 RSpliet: specing: that logic no longer applies if you wish to allow pipelining
16:29 RSpliet: supposedly a clock of 1.5GHz is too high for a full multiply, but chop a 3-2 reduction variant of 33x32 (mul+add) up into four and you still have a multiply-add unit that can work at a rate of 1CPI. For an addition, multiply one of the operands with 1 (if you do it cleverly, you can skip some pipeline stages if design permits), for a mul, set the add operand to 0. That way, you'll save hw on not building a separate adder ;-)
16:32 specing: RSpliet: sure it does, but the pipelining is localised to the execution unit
16:32 specing: OoO is scheduler basically
16:33 RSpliet: Yes, they're orthogonal. as far as I know NVIDIA GPUs are in-order issue, out-of-order execution
16:34 specing: well much more than a scheduler, also a dependency tracker
16:35 RSpliet: ~8 hw threads per (fp) execution unit (simplification) - which is why they'd be able to exploit this kind of pipelining despite having in-order issue
16:35 specing: Yes
16:35 smusiland: Allah is doing
16:36 specing: Someone made a processor that includes a kernel in hardware that has 8-32 threads per core
16:36 smusiland: Sun is not doing, allah is doing
16:37 RSpliet: Niagara springs to mind... but surely there's been lots of research-work since
16:37 specing: but yes, 8 threads means 8 cycles per instruction which is basically very easy to work with as a hardware designer
16:38 specing: RSpliet: https://github.com/azonenberg/antikernel
16:39 smusiland: Skies are not doing, allah is doing
16:40 mupuf: who has banning powers? This is getting old
16:41 RSpliet: back to the original point. If I have to make an arsepull estimate (I'm not experienced on the physical level) I'd say you can do a pipelined multiply-adder in CMOS in 30,000 transistors... that could have been 3KB of SRAM. NVIDIA has 3500 of them on high-end chips, which'd be idk... half a percent of their budget?
16:42 smusiland: You can't ban without Allah permission
16:42 smusiland: You can't die without Allah permission
16:42 smusiland: Computer is not doing, allah is doing
16:42 specing: and you can't get his permission when he doesen't exist
16:42 specing: must be so frustrating
16:43 smusiland: You can't write without Allah permission
16:43 smusiland: Allah has the power
16:43 smusiland: Everyone have to listen to Allah
16:43 smusiland: Has*
16:44 smusiland: Trihgered
16:44 smusiland: Triggered*
16:44 smusiland: Incoming
16:44 smusiland: In
16:44 smusiland: 3
16:44 smusiland: 2
16:44 smusiland: 1
16:44 smusiland: JHON CEEENNAAAAA
16:44 smusiland: BOOM
16:44 smusiland: ALLAH U AKBAR
16:45 smusiland: :(
16:45 smusiland: You can't ban without the permission of Allah!!
16:45 mupuf: specing: yeah, I tried feeding the troll yesterday, it did not get anywhere. The guy is obviously not a bot and has nothing else to do than spam people with fake religious message
16:46 smusiland: You can't be nigger without the permission of Allah
16:46 smusiland: You can't follow non-islam religions withoit the permission of Allah
16:46 smusiland: Niggered
16:46 smusiland: :(
16:46 smusiland: Incominh
16:47 smusiland: In
16:47 smusiland: 3
16:47 smusiland: 2
16:47 smusiland: 1
16:47 smusiland: 1
16:47 smusiland: 1
16:47 smusiland: 1
16:47 smusiland: 3
16:47 smusiland: 1
16:47 smusiland: 3
16:47 smusiland: 1
16:47 smusiland: 1
16:47 smusiland: 1
16:47 mupuf: for fuck sake, good bye!
16:47 smusiland: 0
16:47 smusiland: 0
16:47 smusiland: 0
16:47 smusiland: 0
16:47 smusiland: ALLAH U AKBAR
16:47 RSpliet: mupuf: keep it rated for general audience here ;-)
16:48 mupuf: yeah, he definitely achieved his goal
16:48 smusiland: You can't be jewish without the permission of Allah
16:49 smusiland: You can't drink alcohol without the permission of Allah
16:50 smusiland: You can't ban smusiland without the permission of Allah
16:51 smusiland: Maometto couldn't gain the power without the permission of Allah
16:52 smusiland_: Allah is doing
16:53 smusiland_: mupuf can't ban smusiland without the permission of Allah
16:53 specing: amusing
16:53 mlankhorst: ban his account too: $a:musiland ?
16:53 Lyude: wow, it appears we have been "Trolled"
16:54 mupuf: Lyude: yeah, he started yesterday already
16:54 specing: notice how the uid never changes?
16:54 mlankhorst: was thinking more using his freenode login
16:54 Lyude: mupuf: it is weird to me people still do that stuff on irc
16:55 RSpliet: markov chains get bored
16:55 mupuf: specing: yes, saw it
16:55 mupuf: I banned one guy by mistake and I am reading up on how to invite him back :s
16:56 mupuf: wasting time...
16:56 specing: LOL
16:56 specing: collateral damage
16:56 robclark: hmm, is martm also chatter?
16:57 RSpliet: !mode +b $a:smusiland
16:57 mupuf: RSpliet: why are you adding him back?
16:57 RSpliet: mupuf: +b ban, -b undo ban
16:58 whydoubt: robclark: yes, I've seen martm elsewhere
16:59 mupuf: that should make sure he can come back
16:59 robclark: yeah, he showed up briefly on #freedreno a few minutes ago..
16:59 mupuf: and I sent him a pm
17:01 RSpliet: there... that'll probably keep $troll entertained for a good 15 minutes. Now carry on as if nothing happened folks
17:42 Tom^: indeed , the uid doesnt change unless he changes account on irccloud.com . https://www.irccloud.com/abuse "The ideal ban mask for banning a specific IRCCloud account is: *!*id12345@*.irccloud.com"
17:44 mupuf: Tom^: thanks for the info :)
17:50 karolherbst: who is OP by the way?
17:51 Tom^: uhm the owner of the channel you mean?
17:51 karolherbst: besdines that person
17:51 karolherbst: *besides
17:52 Tom^: marcheu: created this channel 11 years ago
17:52 Tom^: it seems, /msg chanserv info #nouveau
17:52 Pie_Mage: CHANSERV!
17:52 karolherbst: I actually expected serious answers :D
17:53 Pie_Mage:goes back to endless idling
17:54 Tom^: karolherbst: yeah if you have op or "permissions" just run /msg chanserv flags #nouveau and it will list them
17:54 Tom^: i dont :(
17:54 RSpliet: which... reminds me. Maybe time to break a little tradition
17:54 Tom^: what changed?
17:55 Tom^: or am i blind :D
17:55 karolherbst: https
17:55 RSpliet: https
17:55 Tom^: ooh
17:55 Pie_Mage: \o/
17:55 karolherbst: ilia will be sad now
17:55 karolherbst: Tom^: well I can't check the flags
17:56 Tom^: perhaps it requires some flag to be able to see it aswell
17:56 Tom^: *shrug*
17:57 karolherbst: no clue, I have no idea what is going on regarding this anyway
18:05 pmoreau: RSpliet: You could have the logs URL be: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau
18:35 karolherbst: mwk: bit 0 is something memory related
18:36 karolherbst: mwk: maybe even something like "droped below last assignment"
18:36 karolherbst: but I think this is a simple memory watchpoint
18:36 karolherbst: or rather "sp was set to X"
18:39 karolherbst: mhhhhh
18:39 karolherbst: or something else
18:40 karolherbst: got a breakpoint at ld b32 $r13 D[$r14+0x4])
18:40 karolherbst: where $r14 is 0x80000000
18:41 karolherbst: mhh, this doesn't make much sense
18:45 karolherbst: but I am sure it is something memory related
19:00 mwk: bit 0 of what?
19:00 mwk: break mask?
19:01 karolherbst: yeah
19:53 mwk: karolherbst: have you, by any chance, figured how the two continue types differ?
19:55 karolherbst: mwk: what do you mean by that?
19:55 mwk: there are 4 different continue commands
19:55 karolherbst: ahhh
19:55 karolherbst: I remeber
19:55 karolherbst: yeah
19:55 karolherbst: kind of
19:56 karolherbst: I mean, I know what the _from_addr things do... but I think you asked about the unk both
19:56 karolherbst: *two
19:56 mwk: they are clearly two pairs of "continue from current PC" and "continue from new PC"
19:56 mwk: but I have no idea how the pairs differ
19:56 karolherbst: ohhhh
19:56 karolherbst: I have an idea
19:57 mwk: please tell
19:57 karolherbst: maybe the one skips the exectuion of stuff in between and the other not?
19:57 mwk: what kind of stuff?
19:57 karolherbst: instructions
19:57 mwk: what would be the point of executing instructions if you don't want to execute instructions?
19:58 karolherbst: mhh true
19:59 karolherbst: maybe something like execute next after pc/addr or execute instruction at pc/addr? but that would be pointless as well
19:59 karolherbst: I didn't really looked much into that
20:01 mwk: uhh
20:02 mwk: I think we're both idiots
20:02 karolherbst: yes
20:02 karolherbst: most likely something super trivial
20:02 mwk: I can't find the commit where it comes from
20:02 mwk: but I snatched this little thing from gk20a driver
20:03 mwk: before they cleaned it up
20:03 mwk: https://0x04.net/~mwk/hw_pwr_gk20a.h
20:03 mwk: catch
20:03 karolherbst: well, afaik they are still all continue commands
20:03 mwk: and grep for _icd_
20:03 karolherbst: uhhh
20:04 mwk: "run" and "runb", whatever that means
20:04 karolherbst: mhhh
20:04 karolherbst: jrunb
20:05 karolherbst: mwk: maybe clear break_mask?
20:05 mwk: that wouldn't exaclty be useful
20:05 mwk: besides, it appears they call it "emask"
20:05 karolherbst: right
20:05 mwk: now I also wonder what "sbu" does...
20:06 karolherbst: uhh, all special regs are there as well
20:06 mwk: just their names
20:06 karolherbst: yeah
20:07 karolherbst: ohh
20:07 karolherbst: the break_mask is there as well
20:08 mwk: yep
20:08 mwk: 1 bit for every trap
20:08 mwk: + 1 bit for every interrupt, all *3* of them
20:09 mwk: I still want to know what's the fucking deal with iv2
20:09 mwk: by all rights, it should not exist
20:09 karolherbst: emask_iv1_true_f
20:10 karolherbst: I really dislike how they name all those things
20:10 karolherbst: and probably use it as well
20:10 karolherbst: shouldn't that look like super ugly in code?
20:11 karolherbst: probably they used a lot of macros to let it look nice in the end?
20:11 mwk: *shrug*
20:11 mwk: it's quite horrible, yes
20:12 karolherbst: I am wondering why those trap breakpoints didn't hit for me
20:13 mwk: hmm
20:14 mwk: try using the other continue
20:14 karolherbst: I never used one in those tests to begin with
20:14 karolherbst: I just put the trap into my common code and setup 0x200 on the falcon
20:15 karolherbst: maybe things are different if you are inside a interrupt handler?
20:17 mwk: how would the ICD even know that?
22:03 mwk: eh, the 0xf3 opcode is weird
22:04 mwk: it seems to just be an absolute 16-bit call
22:04 mwk: should be redundant with f5 21
22:23 mwk: ok, it's not redundant with f5 21 - they removed f5 21
22:24 mwk: still, NFI why they bothered to make an all-new 16-bit call instruction
22:31 mupuf: mwk: is it really all new?
22:35 mwk: the f3 opcode?
22:35 mwk: probably
22:36 mwk: I mean, I haven't recently verified it doesn't exist on v4
22:36 mwk: but I've never seen it before
22:37 mwk: and Falcon doesn't have truly duplicate opcodes, so the fact that f5 21 exists on v4 strongly suggests that f3 doesn't
22:43 mwk: eh what the fuck
22:44 mwk: if you have $pc pointing to an unmapped page while $cauth bit 19 is set, Falcon just increments $pc by 1 and sets $r0 to 0
22:45 mwk: matter of fact, it always increments $pc by 1
22:45 mwk: even if it triggers a trap
22:45 mwk:wonders wtf happens if an instruction is partially on an unmapped page