00:24 imirkin: airlied: work is relative. it'd probably get things back to where they were.
00:24 imirkin: airlied: imho the proper patch is to change PIPE_CAP_PREFER_COMPUTE_FOR_MEDIA_BLIT -> PIPE_CAP_PREFER_COMPUTE_FOR_MEDIA
00:24 imirkin: and then make use of that throughout vl for deciding whether to use compute or not
00:25 imirkin: but i haven't had the time/motivation to type that up
00:25 imirkin: afaik mareko would agree with such a patch in principle.
00:25 imirkin: [that's not the precise cap name, but it definitely has compute, multimedia, and probably blit in it)
06:21 martsteiner_: very good Thesis from sweden about jtag. http://citeseerx.ist.psu.edu/viewdoc/download?doi=
06:23 martsteiner_: or this one http://www.eeng.dcu.ie/~scaifer/fpgawkii/jtag01.htm
06:27 martsteiner_: Yeah i realized that some GPUs like adreno vliw based and r300 have instruction source modifiers for indirection bits.
06:32 martsteiner_: that would not practically require a delay line or whatever in the regfile, can be parsed in decode stage allready
07:08 martsteiner_: So for SIMD i can see queue entries with indirection bits are scoreboarded like for GCN, if it's based of the delay line , interface might be missing there, but they definitely are scoreboarded in case of regfile delay line, but not sure about VLIW.
07:15 martsteiner_: if the designers did not do a huge mistake, i think indirection from queues should work in correct way on VLIW too.
07:22 martsteiner_: so it would have SRC_REL globals bypassed to future bundles as PV regs there
07:23 martsteiner_: in atari gpu that jaguar one considers it a bug when it does not work so, and to be honest so do I.
07:27 martsteiner_: but if there is that sort of bug present, it can be overcome in software anyways, but blocking on src indirections that write to bypass regs, which are indirected to another instruction simplifies the solution.
07:29 martsteiner_: And for ARM in-order cores and i486 there is a fast path on debug, but I still do not know (it is very complex one) if it can be also secured somehow.
07:30 martsteiner_: once such a pipe is compromised and some random bits sent , it can damage the chip
07:34 martsteiner_: I am entirely unsure, maybe on azure sphere they did something to secure debug pipeline on a7
07:34 martsteiner_: but be that some corruption of the files or uploaded later after signing to commit in the pipe, it would still be a little dangerous
07:47 martsteiner_: on radeon channel there is a guy name jvesely (Works in some university in united states appareantly) has handful of papers published, last one went as far as running RTOS os on gpus, handleling interrupts on modern gpus that of OS ones.
07:54 martsteiner_: I talked the other day about what are threats to fall out all in all to me, as much as I have faced some injustice and scams and hence live with small moneys, some of the plans were ruined are overtaken, i have no such threats that i can not at all earn anything, only some major violations can leave me entirely disfunctional.
07:54 martsteiner_: i have brilliant positive thinking and sane one, i mean I should be able to manage just fine.
07:58 martsteiner_: i see so many easily opened doors, that it is somewhat possible to close them all from me.
08:24 martsteiner_: the way i see, i Prepare for independent run and keep learning and reading daily basis then the meds do not hit me back as hard, and the way i am capable of understanding shit, it'd be still fantastic run for me.
11:43 cosurgi: imirkin, karolherbst: this is a bit strange. I thought that it has crashed, because everything froze. So I went to gdb and typed 'bt full'. I got some backtrace, then I typed 'c' assuming that it will continue crashing and xserver would close. But it didn't. It is still up and running, while I have some backtrace, which I don't know if it's useful.
12:03 cosurgi: ah, I see
12:03 cosurgi: it was a SIGPIPE
12:03 cosurgi: https://paste.ubuntu.com/p/TNMgXFvvjC/
12:03 cosurgi: Thread 1 "Xorg" received signal SIGPIPE, Broken pipe.
12:04 cosurgi: I just closed some window, and some pipe was broken.
12:04 cosurgi: so it's not the crash we are waiting for.
12:04 cosurgi: it's not a crash actually :)
12:05 cosurgi: okay, let's keep waiting.
12:07 cosurgi: Now that I learned how to attach gdb to nouveau-xf86-video-nouveau I think I will do this always.
12:07 cosurgi: But also I see something strange: last commit in this repository was 2 years 2 months ago?
12:07 cosurgi: origin https://github.com/freedesktop/nouveau-xf86-video-nouveau.git
12:10 cosurgi: I though you told me that there were some more recent improvements.
12:12 cosurgi: 69aecdd (HEAD -> master, origin/master, origin/HEAD) (2 years, 2 months ago) Adam Jackson modesetting: Validate the atom for enum properties
12:13 cosurgi: imirkin: should I try another branch ?
12:16 cosurgi: hm, I think I found the right repo: nouveau-xf86-video-nouveau
12:16 cosurgi: hm, I think I found the right repo: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/log/
12:16 cosurgi: now I need to find out how to clone it
12:17 cosurgi: ah, this one perhaps: git://anongit.freedesktop.org/nouveau/xf86-video-nouveau
12:17 cosurgi:git remote add upstream git://anongit.freedesktop.org/nouveau/xf86-video-nouveau
12:18 cosurgi:git remote rename origin github-OLD
12:19 cosurgi:git remotr update
12:19 cosurgi:git remote update
12:19 cosurgi:git branch --set-upstream-to upstream/master
12:19 cosurgi:git pull
12:19 cosurgi: ec2b45d (HEAD -> master, tag: xf86-video-nouveau-1.0.16, upstream/master) (7 months ago) Ilia Mirkin Bump version to 1.0.16
12:19 cosurgi: much better now, I think.
12:19 cosurgi: Now I have to start this xserver again
13:15 cosurgi: Much better now:
13:15 cosurgi: [2323660.357] (II) Loading /home/deb/test-nouveau/nouveau_drv.so
13:15 cosurgi: [2323660.357] (II) Module nouveau: vendor="X.Org Foundation"
13:15 cosurgi: [2323660.357] compiled for 1.20.4, module version = 1.0.16
13:59 cosurgi: I will attach all my xservers to gdb :)
13:59 cosurgi: I just hope that the git revision is correct.
14:14 cosurgi: Bring it on!
14:15 cosurgi: Now every new xserver will use /home/deb/test-nouveau/nouveau_drv.so with debug info. And gdb is tracking them.
14:15 cosurgi: Whatever crash is comoing, I won't miss it!
16:15 cosurgi: karolherbst: thanks for telling me about gdb
16:18 cosurgi:feels much more poweful now.
16:18 cosurgi: I will grab this crash by the neck, andnail it.