00:01gnurou: imirkin: basically, these guys: https://github.com/kfractal/nouveau/commit/31964fd7d11ba3601a56b92777771b78b4f0f358
00:02gnurou: would replace hardcoded registers and bit-fields with proper names
00:02imirkin: what's "drf"?
00:02gnurou: Device Register Field :)
00:03gnurou: here is an example usage: https://github.com/kfractal/nouveau/commit/7fad3bda21b99e264f413bedfb9b1c35f00531cc
00:03imirkin: my stance, which probably holds limited weight, is that it's all-or-nothing... that said if it was in just files named gk20a, i wouldn't care too much.
00:03gnurou: (final macros will be shorter than in this example)
00:03imirkin: [or gm20b]
00:04gnurou: well it would mostly affect new code I believe
00:05mupuf: hmm, on the one hand it helps documentation. On the other, it is super verbose but helps catching stupid errors like the one I made for the voltage control
00:05gnurou: replacing all older code would be pretty time-consuming
00:05imirkin: gnurou: not to mention would require generating the docs in the first place :p
00:06gnurou: generating the docs?
00:06imirkin: gnurou: well, the headers
00:06gnurou: ah right
00:06imirkin: with all the register names
00:06imirkin: we use a lot of them
00:06imirkin: the other problem is rnndb integration
00:06imirkin: basically right now i can take a mmiotrace of blob driver
00:06imirkin: and attempt to match it up to what nouveau is doing. or grep around relatively easily if i know what i'm doing
00:07imirkin: having register numbers in both places helps that a lot
00:07imirkin: with symbolic names it's constantly looking things up all over
00:07imirkin: unless there's rnndb integration
00:07gnurou: yeah, eventually I would like all the information that is used for these to be merged into rnndb, and have the headers generated from it
00:07gnurou: but according to Ken there are some conflicts with existing information
00:08gnurou: don't know what precisely
00:08imirkin: either your docs or our docs are wrong :p
00:08gnurou: and in that case, who should take precedence? :)
00:09imirkin: the guys with the real docs, obviously
00:09imirkin: but yeah, it'd be a significant project
00:09gnurou: if rnndb integration is a requirement, we can try to work towards it - for now I'm wondering whether injecting the headers files as-is would be a satisfactory first step
00:09sooda: the macro magic looked easy enough to tweak into generating some symbolic name database for rnndb. if the mmiotrace would look at that and map the trace to the names, then grepping would be as easy as with numbers
00:09mupuf: gnurou: add yours as a comment when there is a conflict :p
00:09imirkin: however if there were commitment to completing it, it could be done piecemeal
00:10imirkin: sooda: mmiotrace does use rnndb for lookups
00:10imirkin: sooda: or rather, demmio does
00:10sooda: (disclaimer: i've never used those yet)
00:10gnurou: so rnndb is definitely the right place to put that in
00:14gnurou: so as I understand it, nobody objects that these macros are a good alternative to hardcoded mmio addresses and bitfields? :)
00:15imirkin: no, my objection is purely to having it be partially converted
00:15imirkin: although it raises an interesting point
00:15imirkin: let's say you guys generate all the docs, and we convert over
00:15imirkin: and then we want to add some feature
00:16imirkin: which uses some undocumented register
00:16imirkin: then what
00:16imirkin: start throwing in UNK1234's all over? i guess that wouldn't be the worst thing in the world...
00:17sooda: the headers are huge, so i suppose there aren't too many of undocumented regs... but adding UNK* names into the headers would at least be consistent
00:17gnurou: aren't the released engines fully documented? I would expect that, so there should not be missing registers
00:17imirkin: gnurou: if you say so. it appeared that it was the minimum amount of regs in each engine
00:18imirkin: but i could have looked at an older version. or misunderstood the organization.
00:19gnurou: imirkin: I am not sure myself, but the coverage seems exhaustive at least
00:20mupuf: we could have a different folder with headers not coming from nvidia
00:20mupuf: this way, no conflicts
00:21mupuf: and yes, we have regs that we documented, use and you did not document
00:21imirkin: gnurou: so you're telling me that every PGRAPH and PFB register is documented?
00:21mupuf: especially in ptherm
00:21imirkin: gnurou: which means with a bit of guessing, we should be able to figure out all the isohub stuff too?
00:22gnurou: imirkin: I am not saying that - let me confirm with Ken
00:22gnurou: mupuf: ok, so if ptherm it incomplete, there is no reason to expect other engines to be completely covered
00:22gnurou: although I wonder *how* the released registers got selected
00:22mupuf: but there are ways around it :)
00:23mupuf: probably based on nvgpu's needs
00:23skeggsb: gnurou: as i understand it, it's the list gk20a nvgpu used, extrapolated back to earlier chipsets
00:23skeggsb: my sole objection to the idea is the incompleteness and having part of the driver completely different to the rest
00:26mlankhorst: can't have the whole driver documented at once :)
00:26gnurou: skeggsb: we can certainly release more stuff in the future - but we need to start somewhere
00:26gnurou: mlankhorst: exactly
00:26sooda: i suppose that nvidia has also internally some list of publicly-releasable regs, which probably doesn't cover everything and adding one line to the headers needs some legal bullshit round
00:27gnurou: also it seems like some internal developments have started using these macros... we will be in upstreaming hell if we don't find a way to merge them somehow :/
00:27sooda: even the trm doesn't cover many important parts of other things. it's a joke, not properly maintained
00:31skeggsb: gnurou: yes, it'll be a process to get everything moved over
00:31skeggsb: given past experiences, i wonder at what kind of lag we're talking about / if it'll actually eventuate
00:32skeggsb: having the process started of the "low hanging" bits we touch (grep nvkm_* use, i guess) and having them go through review and get into the headers would be a decent start, that way the burdon of actually modifying the "old" code isn't entirely on you guys, all of us can chip away at it
00:33skeggsb: i wouldn't even care if it wasn't *completely* documented, and only the bitfields we currently touch were covered etc. of course, ideally it'd be everything, but, small steps ;)
00:34skeggsb: brb in a bit, dinner time
00:35gnurou: skeggsb: yep. What I am seeking for at the moment is an overall agreement that these macros are a good direction to move to, because we have started investing in them
00:35skeggsb: yes, i don't object to the idea at all
00:35gnurou: skeggsb: so if we cannot get them merged eventually, we will need to rethink a lot of things and we'd rather do it now :)
00:35skeggsb: i don't expect any of us do
00:35gnurou: skeggsb: excellent then, thanks
00:36gnurou: skeggsb: I also suppose a submission to rnndb is preferable to the headers being directly submitted?
00:37imirkin: you suppose correctly. and note that headergen can be rewritten at will.
00:37imirkin: e.g. freedreno uses rnndb and a totally different header generator
00:37skeggsb: gnurou: i, personally, don't mind about that either way... but that's mostly because i rarely use it
00:38gnurou: rnndb makes more sense, definitely - but keep in mind that some exiting names will very likely get changed
00:39imirkin: gnurou: afaik nothing relies on the current names
00:39gnurou: i.e. we will overwrite without consideration :) but hopefully this will be the "correct" data
00:39skeggsb: your names are preferable anyway :P
00:39gnurou: actually I think Ken attempted a merge to envytools in the past, but it got rejected for some reason...
00:39imirkin: gnurou: but please talk to me before touching any of the 3d class docs -- those *are* used in the mesa driver, extensively.
00:40imirkin: we can look into doing a giant rename, but it'd have to be done with love and care
00:40imirkin: gnurou: iirc he was doing it in a very non-rnndb way
00:41imirkin: gnurou: ideally you have one register once and mark it with variants it applies to
00:41gnurou: aha, I see
00:42imirkin: his generator was a bit more brute-force than that
00:42gnurou: yeah, and it only covered gk20a
00:42gnurou: but since his second-attempt headers were properly generated for all GPU generations, I believe we can achieve the desired result for rnndb
00:43hakzsam_: imirkin, you are going to have major headaches if you try to re-generate all headers :) but sounds like a good idea
00:43gnurou: well, that's gonna be some work of course
00:43mlankhorst: quick add unk1234 everywhere
00:44imirkin: hakzsam_: would have to create a remap table + clever awk script
01:10gnurou: uh, I kind of understand why Ken gave up on importing the data into rnndb
01:10gnurou: it seems impossible to do properly
01:10gnurou: e.g. the bitsets that are reused by several registers... there is no way we can preserve that
01:12imirkin: those could be factored manually... it's pretty rare
01:12imirkin: you could also build a cache into your generator
01:12imirkin: and if you see 2 identical lists, factor them out
01:12gnurou: ... or just ignore such things, what are they for besides making the xml smaller?
01:17skeggsb: i don't entirely find that easier tbh, it means skipping around when reading it
01:22imirkin: but then you notice that regs 1, 2, 3, 4, 5 are all about the same thing
04:24karolherbst: mupuf: okay, seems I was wrong about the pwm value. The voltage set seems to be right indeed
04:24karolherbst: didn't had any crashes after your pwm fix
04:31imirkin: sweet, my atomic counter code also works on fermi. i guessed it would, but only just now confirmed.
04:37karolherbst: imirkin: with what does those atomic counter stuff helps? less overhead doing atomic operations?
04:58karolherbst: I see
05:50RSpliet: karolherbst: they *are* atomic ops :-P
05:51RSpliet: very useful for OpenCL as well
05:51imirkin: mildly useful in GL imo, but... it's part of the spec
05:52karolherbst: RSpliet: well I was thinking about native vs emulated atomic operations
05:52imirkin: way easier to implement than images ;)
05:52RSpliet: karolherbst: I don't think you can really emulate an atomic op without cache coherence
05:52karolherbst: RSpliet: well libraries still do
05:53karolherbst: pre ARMv6 only has swap as atomic operations, everything else is emulated
05:53RSpliet: I thought it always had load-linked, store-conditional?
05:53karolherbst: nope, only swap
05:54RSpliet: did you have dual-core ARMv6's?
05:54karolherbst: I said pre ARMv6
05:54karolherbst: no, but there is a reference to that in the glibc source
05:55RSpliet: because atomics don't make a huge deal of sense in single-core machines with no or physically tagged caches
05:55karolherbst: you don't know compiler well enough, do you? :p
05:56karolherbst: C++ is a bitch here
05:56RSpliet: doesn't have much to do with the compiler
05:57RSpliet: as long as you don't get a context-switch mid-addition you should be fine... it's a whole different kind of emulation compared to what you'd do on a (massive-) multi-core machine
05:57karolherbst: yeah right
05:57karolherbst: but in the emulation code you can get a nasty context switch
05:57karolherbst: that's what I menat
05:58RSpliet: yes, I got that
05:59karolherbst: anyway, that's what I thought imirkin did: add some native atomic support hence removing overhead through emulation code
05:59RSpliet: nah, you can't emulate atomics on an NVIDIA GPU
05:59karolherbst: I see
06:40karolherbst: what do you think about this? https://gist.github.com/karolherbst/bc807c678588798603ff
06:40karolherbst: while the gpu is off
06:42karolherbst: the patch looks a bit hacky though: https://github.com/karolherbst/nouveau/commit/a00fe8e693f0e73f20e59397f67347b47cf9c45d :/ I really want to do it cleaner
06:43imirkin_: could avoid calling it in the first place
06:48karolherbst: I thought it is a good idea to print the current pstate table nethertheless
06:48karolherbst: mhh maybe
06:49karolherbst: imirkin_: mhh the fixed shouldn't be inside debugfs, because those interfaces are designed to be used also from userspace applications afaik
06:49imirkin_: you can still get the pstate table
06:49imirkin_: just don't get the current pstate info
06:49imirkin_: "the fixed"?
06:49imirkin_: right now this is all very debugfs-appropriate
06:52karolherbst: I know, but the thing is, that nvkm_clk_read is called when the gpu is off, even if we fix that in sysfs/debugfs, another caler might mess that up
06:52karolherbst: that's why I want to rather fix that inside device/ctrl
06:54imirkin_: so just do like
06:54imirkin_: if (!pm_runtime_on()) return -EAGAIN
06:54imirkin_: instead of filling in bogus data
06:55karolherbst: mhhh right, this thing is called for every pstate
06:55karolherbst: yes, that was too easy for me :D
06:55imirkin_: i mean in the bit where it actually reads stuff
06:55imirkin_: but so what... every nvif call has to check for pm_suspended now?
06:55imirkin_: seems a little crazy
06:56karolherbst: mhhh no, only if they read something out of the gpu
06:56imirkin_: which is like 99% of them
06:56karolherbst: it depends
06:56karolherbst: I think if we actually care enough we shold fix that
06:56karolherbst: currently echoing something into pstate is not a good idea while the gpu is off
06:56karolherbst: locks the process until I don't know
08:53Lekensteyn: With runtime PM enabled, is it possible to disable the GPU when no external monitor is connected (on Optimus laptops)?
08:54imirkin_: it should auto-disable
08:54imirkin_: it should say 'DynOff' in vgaswitcheroo
09:16Lekensteyn: imirkin_: oh right, it does that automatically. Neat!
09:54karolherbst: mupuf: I was thinking a bit about the pdaemon host communication regarind reclocking. I think if we are smart enough, it's entirely possible to do that without needing ACKs from the host at all
10:04karolherbst: mupuf: I think all of the acks can be implicilty optimized away, and also the need of knowing the pstate/cstates and everything
10:16karolherbst: mhh how can I call stuff from a falcon on the host?
10:16vedranm: imirkin_: OK
10:17vedranm: is Fermi the only series where compute is enabled at the moment?
10:17imirkin_: karolherbst: you feed the data port iirc
10:17imirkin_: vedranm: no, kepler and soon tesla will have it "enabled"
10:17karolherbst: imirkin_: I mean I know how I can send data to the host after the host called something on the falcon
10:17imirkin_: vedranm: but that enablement won't do an end user any good
10:17karolherbst: but now I have like a timer thingy on the falcon and this thing decides now to send somethiong to the host
10:18imirkin_: karolherbst: intr
10:18vedranm: imirkin_: will it run at least hello world stuff?
10:18vedranm: like, sum 2 vectors
10:18imirkin_: vedranm: yes and no... if you write that program appropriately, yes. but not in any standard way.
10:18karolherbst: imirkin_: okay, I guessed that much... mhh do I have to set a bit inside 0x10a008 and handle that bit inside nvkm_pmu_intr?
10:19imirkin_: karolherbst: something like that
10:19vedranm: imirkin_: OK
10:19karolherbst: imirkin_: and I bet htere are reserved bits for falcon only usage
10:19vedranm: regardless, it's an epic milestone
10:19imirkin_: karolherbst: there's a way to generate intr's from the falcon, but tbh i don't know what it is. pretty sure we do it elsewhere though.
10:19imirkin_: vedranm: one that was reached years ago
10:19vedranm: imirkin_: so you mean that
10:20vedranm: 's just a bool setting somewhere that was switched and no particular improvements were done recently?
10:20imirkin_: vedranm: that's right.
10:20imirkin_: well, very minor improvements.
10:20imirkin_: to make it conflict less with the 3d pipeline on fermi, making it enableable by default
10:25vedranm: imirkin_: I see
10:25vedranm: thanks for the info
10:26vedranm: to be honest, I am very sad we have no open source compute on either radeon or nvidia
10:26imirkin_: vedranm: radeon supports OpenCL 1.1
10:26karolherbst: intel too
10:26vedranm: imirkin_: yes, but it has no image support
10:27imirkin_: vedranm: that's different than "no open source compute" :p
10:27vedranm: karolherbst: does intel beignet offer image support?
10:27vedranm: imirkin_: you are right
10:27imirkin_: i think so, yea
10:27karolherbst: no idea, never test it
10:27vedranm: looks worth giving a shot, but I have no Intel CPU anywhere >D
10:28karolherbst: well :D
10:28karolherbst: opencl on the intel hd isn't that fast
10:28karolherbst: it's faster in total when you use the cpu and the gpu
10:28karolherbst: but still
10:28vedranm: even on Win? limited hardware?
10:28karolherbst: tested on linux
10:29vedranm: thx for the info
12:08ulteq: sorry forgot the /
12:30imirkin_: skeggsb: btw, did you see my question about GF117 pmu? it's not hooked up and causes an oops on v4.3... probably should hook it up right? (and cc that to stable)
12:51imirkin_: joi: hakzsam_ has a trace where the compute channel for some reason isn't coming up in demmt -- it's a cuda app -- http://people.freedesktop.org/~hakzsam/traces/gt218/ (the cuda + gl trace)
12:52imirkin_: joi: i haven't super-investigated it yet, but perhaps you have a few to take a glance and point me in the right direction?
12:52imirkin_: joi: it's fd 26 which has the pushbuf, but i don't remember how exactly that info is communicated to the kernel
12:52imirkin_: (i'm sure you do)
13:11imirkin_: joi: oh i see... looks like they have 2 separate IB's open
13:11imirkin_: and demmt likes for there to only be one
13:13pmoreau: imirkin_: Hey! :-) Do you have any advice on how to debug / find which optimisation pass is messing some registers assignment?
13:13imirkin_: pmoreau: yeah, try with NV50_PROG_OPTIMIZE=0
13:13imirkin_: then =1
13:13imirkin_: then =2
13:14imirkin_: figure out which one it fails on
13:14imirkin_: then manually bisect the pass list by commenting stuff out
13:14pmoreau: I have something like `a = f1(b); c = f2(a)` and this gets converted to `a = f1(b); c = f2(e)`, with `e` that was never set nor used
13:14imirkin_: pmoreau: if you want me to look at it
13:14imirkin_: you know what i like to see :)
13:14pmoreau: backtraces! :D
13:15imirkin_: full debug logs
13:15pmoreau: Just kidding
13:15pmoreau: I will put them some where :-)
13:19pmoreau: I'll paste the NV50 IR generation code, I'm sure I'm doing a lot of things wrong
13:20imirkin_: pmoreau: original code might be nice too
13:22imirkin_: er what
13:22pmoreau: It's not the whole source code though
13:23pmoreau: The remaining parts are scattered all around, but the generation does work for it.
13:24imirkin_: your code looks wrong on many levels
13:24imirkin_: level#1: why do you a do a cmp for the "else" case? shouldn't that just be an unconditional branch?
13:24imirkin_: level #2: you're using tree edges everywhere!
13:25pmoreau: I have no idea what those tree edges are, I just saw them being used in nv50_ir_from_tgsi and tried to use them as well. :/
13:25imirkin_: i explain it here:
13:27pmoreau: level#1: The else case is not really an else case: I first branch for id==0, then id==1, and then id!=2. That id!=2 case is what I name the else case. but I still need the comparison, as otherwise I do the id==2 case.
13:27imirkin_: you can't have code the way you have it :)
13:28imirkin_: so every BB has to be organized thusly:
13:28imirkin_: code. branches.
13:28imirkin_: code can't contain any branches, and branches can't contain any non-flow ops
13:29imirkin_: that's the point of a basic block -- it has no branches :)
13:29imirkin_: you also have to set join bb's & co
13:29pmoreau: Hum… I followed SPIR-V, where every BB ends with a branch, so I tried to add each BB after a branch
13:29imirkin_: otherwise you get eternal sadness
13:30imirkin_: look at you rbb
13:30imirkin_: you have ne %r8 bra BB:4 in the middle
13:30imirkin_: you can't have none of that
13:30imirkin_: you could do all your comparisons first
13:31imirkin_: and then have 2 conditional branches at the end -- that's kosher
13:31pmoreau: Oh!! That's true
13:31imirkin_: anyways, codegen makes a lot of assumptions about how code is structured
13:32imirkin_: and will happily eat your code if you violate them
13:32pmoreau: I completely forgot about those conditional branches in the middle of the BB
13:33imirkin_: also if you make Converter an instance of BuildUtil, then happy-times
13:34pmoreau: Converter inherits from BuildUtil, I followed the same path as from_tgsi, or your LLVM branch maybe
13:36imirkin_: pmoreau: so why all the nv50_ir::BuildUtil::foo junk?
13:36imirkin_: don't tell me i did that in my spir converter...
13:37imirkin_: if i did, i might have had a reason, like namespace collision with llvm
13:37pmoreau: I like to be explicit to be sure from those functions come
13:37pmoreau: No, you didn't IIRC
13:37pmoreau: s/from/from where
13:37imirkin_: it was a bit annoying since there was nv50_ir::Function and llvm::Function (and so on)
13:37imirkin_: leading to tons of type confusion
13:48imirkin_: is that like "in regards to the illegal op"? :)
14:03glennk: polite hardware
14:09karolherbst: RSpliet: can you help me with how to send and interrupt from a falcon to the kernel?
14:17skeggsb: imirkin_: yes, we should probably wire that up
14:18imirkin_: gnurou's patch accidentally fixed the crash btw
14:18imirkin_: or rather... the fix was on purpose, but accidental wrt GF117
14:19karolherbst: skeggsb: hi, by any chance, do you know how I can send data from an falcon timer interupt to the kernel?
14:58karolherbst: yay, it seems to be easy to do actually :/
14:59RSpliet: oh yes, sorry, I wasn't around :-P
15:00karolherbst: no worries
15:00karolherbst: I just have to call(send)
15:00karolherbst: it was just too easy for me :D
15:00karolherbst: or I lacked the needed creativity to just try that out
15:00karolherbst: mhh ohh wait, nvm
15:00karolherbst: then I need to handle that in nvkm_pmu_recv I guess
15:04RSpliet: yep, otherwise I take it it's just discarded
15:07karolherbst: okay, I think I can work with that
15:24karolherbst: nooo my cursor went missing :/
15:31pmoreau: Seems to work better now. :-)
15:31pmoreau: Still a couple of things to fix, but the control flow should be in a better shape
15:31imirkin: now that you don't have control flows in the middle of bb's?
15:31pmoreau: (Couldn't be much worse I guess)
15:31pmoreau: Eh eh!
15:32john_cephalopoda: Hey, I had a few problems with framerate over the last days but it turns out that I didn't compile mesa with 3d accel. Everything is so fast. I just wanted to say "thank you" for your great work.
15:32imirkin: pmoreau: and it's inserting joinat/join's yes?
15:32john_cephalopoda: Bye! :)
15:33pmoreau: imirkin: https://phabricator.pmoreau.org/P60
15:33pmoreau: With the insertConvergenceOps? Not yet
15:34pmoreau: And https://phabricator.pmoreau.org/P61
15:34imirkin: ok, that means you're still doing something slightly wrong
15:35imirkin: but the join's are not required
15:35imirkin: they're just there to have good performance
15:35pmoreau: Well, I could learn about them while I'm at it
15:36pmoreau: The join is the insertConvergenceOps, right? Or is there something else that I missed?
15:36imirkin: i forget the details
15:36imirkin: and i forget how they appear
15:36imirkin: sorry :(
15:36pmoreau: No problem
15:37imirkin: wtf. and u16 $r0 $r0 0x0003
15:37imirkin: is that a thing?
15:38pmoreau: Hum, the aim was $rX = $r0h & 0x3
15:38imirkin: is *that* a thing?
15:39imirkin: not according to envydis
15:39imirkin: er, envyas
15:40pmoreau: local_id(1) == $r0h & c1[0x0] according to tracing the blob, and for some reason I extrapolated that c1[0x0] == 0x3
15:40imirkin: what opcode do they actually use
15:43pmoreau: One sec, I messed somewhat some traces
15:44pmoreau: `d0840201 00400780 and b16 $r0l $r0h c1[0x8]`
15:46pmoreau: Oh right, for some reason, rather than comparing to 1 or 2 for the dimension, they compare to c1[0x0] and c1[0x4].
15:46imirkin: yeah, *that* works
15:47imirkin: but you can't have a 32-bit result with 16-bit sources for those alu ops
15:47imirkin: only for mul
15:47imirkin: (and mad)
15:49pmoreau: Hum, need to change the loadImm to mkImm
15:49pmoreau: As loadImm is generating an u32
15:49imirkin: and u16 %r7 %r2 %r10 -- that's no good
15:49imirkin: well, you can just make a 16-bit variant of loadImm
15:49imirkin: or a loadImm16 to be explicit
15:49pmoreau: True :D
15:50imirkin: i'm always pretty afraid of doing something dumb with those type overrides
15:55pmoreau: Once it works, I'll try to find out where that function (and similar ones) could be placed, as they are independent of the input IR
15:55pmoreau: So Hans can easily reuse them as well
16:03joi: imirkin: if you move pb_pointer_found to be per device, it should work(tm)
16:04imirkin: joi: ah yeah. i'm going to have to investigate what the various data structures are :)
16:06joi: basically move this variable to struct nvrm_device, add getter/setter and use it in buffer_decode
16:07joi: look at nvrm_get_chipset for inspiration ;)
16:07imirkin: ok thanks
16:08imirkin: joi: i also need to figure out a good place to print texture/sampler descriptors for kepler+...
16:08imirkin: i'm thinking at draw time or something
16:10joi: what changed from previous gens?
16:11imirkin: joi: bindless
16:11imirkin: no more BIND_TSC/BIND_TIC
16:11joi: so how it's selected?
16:12imirkin: you decree that constbuf N shall contain references to tic/tsc's
16:12imirkin: and then the texture instruction knows to read from that constbuf
16:12imirkin: (and there's a pushbuf method to set N)
16:13imirkin: so i have to keep track of which constbuf is N... and that can map to a diff buffer for each shader type, great
16:14imirkin: alternatively i can track uploads to the TSC/TIC buffers
16:14imirkin: that might be easier
16:15joi: but it won't work if blob will write tsc/tic data in non-sequential manner, right?
16:16joi: (or patch part of it)
16:16imirkin: i'll shoot it.
16:16imirkin: non-sequential is fine
16:16imirkin: since i know where the buffer is
16:24imirkin: mlankhorst: were your max-texture-size tests running -fbo -auto, or were they displaying things to the screen?
16:25karolherbst: yay, it works
16:27karolherbst: 0xff000000 pcie 0x00ff0000 memory, 0x0000ff00 video and 0x000000ff core, and currently I only check the core
16:27karolherbst: and this is run every 0.1 seconds on the pmu
16:29karolherbst: so who want to try out dyn reclocks on gt215+ cards tomorrow?
16:35gnurou: imirkin: re: 7:18, which crash are you talking about?
16:36gnurou: Time of your message :)
16:36imirkin: in what tz?
16:37gnurou: Damn >_<
16:37imirkin: sorry, i totally forgot what i said, nor can i find it
16:37gnurou: You mentioned a patch of mine that accidentally fixed a crash
16:37imirkin: the pgob thing
16:37imirkin: where it assumed that there was a pmu
16:38imirkin: but there isn't one for gk20a
16:38imirkin: which is on purpose
16:38gnurou: Ah, that one
16:38imirkin: but there's also not one for gf117, which is accidental
16:38gnurou: I was hoping something more spectacular :)
16:38imirkin: nope, just that one-liner
18:28airlied: gnurou: please reply to Andrew asap :)
18:28gnurou: airlied: yep - I'm not sure what a proper fix will be though :/
18:29gnurou: I'm afraid this workaround is the best we will have for the time being
18:29airlied: I'll apply my hack for now
18:29gnurou: sounds good
18:30gnurou: I will check again whether there is no other way to do what we need and wil reply to Andrew
22:42skeggsb: imirkin: i've got some more fixes to come, and some additions to the ones already there.. didn't quite finish the series today, but what's in the tree now should work well enough for what you want
22:43skeggsb: imirkin: and the ce issue - airlied's patch on mesa3d-dev fixes the cause of it too
23:45mlankhorst: imirkin: -fbo -auto in parallel
23:49airlied: skeggsb: does something traverse the instobj list? surely something must and that would need locking