01:48mooch2: mwk, can you please explain to me da heck the ifc size in parameter does on sifc?
02:08mwk: mooch2: well do you know what sifc does?
02:08mwk: concepturally, it copies a rect from a cpu command stream to gpu memory
02:08mooch2: scaled image from cpu
02:08mooch2: don't worry, i've got it
02:08mwk: size in is the dimensions of the input image
02:08mwk: size out is the dimensions of the output image
02:08mooch2: i just don't know how the data part of it works
02:09mwk: data is plain old packed pixel data
02:09mooch2: ya know, when you write the data for the sifc
02:09mooch2: yeah but where does it go when there was no output surface initialized?
02:09mwk: well you have to have a surface initialized
02:09mwk: otherwise the whole thing blows up with one of the errors
02:10mooch2: oh, weird
02:11mooch2: and da heck happens when on nv3, it sends an obj class of 0?
02:12mwk: you get an invalid method error
02:12mwk: on every method
02:17mooch2: on nv3 sifc, how does one specify the output surface? mwk
02:17mooch2: i see writes to method 0x31c and method 0x3fc for instance
02:20mwk: it uses the global surface
02:20mwk: nv3 has 4 surfaces total
02:20mwk: the grobj specifies which of the 4 it renders to
02:20mwk: and the 4 surfaces are set up by graph registers
02:21mwk: surface offset & pitch registers, as well as canvas in & out size regs
02:21mwk: the surf offset & pitch regs are settable by methods on the SURF objects; the canvas regs are onlys ettable by MMIO
02:23mooch2: ah okay
02:24mooch2: uh, maybe you can help me with this code, i have no idea dafuq i'm doing wrong, at some point, it just bails trying to submit methods
02:24mooch2: shortly after submitting 0x03200258 to SIFC method 0x404
13:01pmoreau: karolherbst: There is an “easy” way to generate PTX out of OpenCL kernel: run the program with the NVIDIA driver and retrieve the binary of the program: the binary is PTX code.
13:09pmoreau: karolherbst: Found an even easier way: https://github.com/ljbade/clcc it calls the NVIDIA compiler directly, so no need to even run the OpenCL program.
15:36oday: Hello again, now I'm trying to set up virtualgl with nouveau and virtio-gpu
15:37oday: With nouveau running the 3D X server, and virtio-gpu running the 2D one
15:38oday: I've run vglserver_config and set everything to the least secure option
15:38oday: (This is all local anyway, and I'd rather not deal with auth as well yet)
15:39oday: So after that, I started a TurboVNC server on :0 and straight up X on :8
15:39oday: Thing is, I don't know how to connect them via VirtualGL
15:40oday: And the official documentation pretty much says "Start the display manager and it'll sort itself out"
15:42oday: So how do I do that
15:48Kazumi621: ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)dwney: gnarface bonbons thc202 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
15:48Kazumi621: ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)afcxocoyz: mmu_man NolanSyKinsley thc202 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
15:48Kazumi621: ▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)pzhuyfwub: oday towo` mmu_man ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
15:51infinity0: i just built and installed skeggsb's devel-clk branch on a fermi gpu, how do i verify that the reclocking worked?
15:51infinity0: RSpliet: ^
15:52lead__597: ▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)deqkorjlgw: towo` bonbons karolherbst ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
15:52lead__597: ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)ijqmfpqsdm: infinity0 NolanSyKinsley gnar ▄▄▄▄▄▄▄▄▄▄▄▄
15:52lead__597: ▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)rfojcrkzz: infinity0 CoreDuo karolherbst ▄▄▄▄▄▄▄▄▄▄▄▄▄
15:52lead__597: ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)amymbgs: damke karolherbst sarnex ▄▄▄▄▄▄▄▄▄▄▄▄,
16:05infinity0: hm, no "reclocking" message in dmesg either
16:18jamm: really annoying these bots
16:33infinity0: ok it looks like it works
16:33infinity0: echo 07 | sudo tee /sys/kernel/debug/dri/0/pstate
16:33infinity0: increases starcraft 2 FPS from 4 to 15-20, very decently playable
16:33infinity0: 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1)
16:34infinity0: however 0f causes my screen to go completely grey and keyboard/mouse stops responding
16:34infinity0: via ssh dmesg, I see lots of:
16:34infinity0: [ +0.000048] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 100c80 [ IBUS ]
16:34infinity0: skeggsb, RSpliet: ^ this is the devel-clk branch on a fermi GF114
16:35infinity0: forward-ported to 4.15-rc5 nouveau sources, but compiled against 4.14 headers
16:35infinity0: and running in a 4.14 kernel
16:49imirkin: infinity0: so ... 50% of the way there :) and RSpliet was right - nvce needs more work.
16:50imirkin: infinity0: if you'd like to help work this out, stick around, there will be a lot of mmiotracing in your future
16:50infinity0: sure, i'll be around :)
18:36imirkin: i couldn't handle all the idiocy being said on phoronix, so in an effort to set things straight which i'm sure won't work, i wrote up a long explanation of how nvidia / nouveau stuff works. read at https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998427#post998427 if you're interested.
18:38karolherbst: imirkin: ugh.. I didn't even bother replying :)
18:39imirkin: not much one can do. but every so often it just boils over.
18:41karolherbst: right, that open source vbios thing is always a bit annoying, but you could open up the bios/uefi code or write a replacement
18:44karolherbst: imirkin: also vbios is signed since maxwell2 already
18:44imirkin: i know
18:44imirkin: did i say something counter to that?
18:44karolherbst: it kind of sounds like it started with pascal
18:45imirkin: it matters with pascal
18:45karolherbst: "owever Pascal has an entirely different memory controller, so a new reclocking script generator would need to be developed. Except the NVIDIA drivers now ensure that the VBIOS hasn't been tampered with, which means that script development is limited to the specific GPU used for the RE."
18:45imirkin: coz it's a different mem controller
18:45karolherbst: but also with maxwell2 a little
18:45karolherbst: skeggsb said that the kepler stuff shouldn't work on maxwell :)
18:45karolherbst: or rather
18:45karolherbst: it works by accident
18:46karolherbst: not quite sure how much work we still have on maxwell2, but generally the memory reclocking chance is lower than on kepler
18:46karolherbst: or this is at least the feeling I get
18:46imirkin: i like accidents.
18:46imirkin: esp happy ones
18:47imirkin: i mean ... clearly like 99% of the reclocking code isn't _really_ necessary
18:47imirkin: see e.g. the gk208 thing
18:47imirkin: where we were moving 0's into regs instead of immediate values
18:47karolherbst: well right. I didn't really asked about the differences and in the end I don't care as long as it runs and there is no obvious harm
18:48imirkin: i.e. the fire starts later, not instantly ;)
18:48karolherbst: I could see that we might reduce the life time of GPUs by doing weird things, but then again: we don't know better and we never will be able to
18:48imirkin: research shows that research causes cancer in mice :)
18:50karolherbst: actually it was the first time somebody said that nouveau stole some nvidia code
18:50karolherbst: the first time I read about it
18:50karolherbst: does this happen more often?
18:50imirkin: yeah, that's the bit that pushed me over the edge.
19:25imirkin: okkkk... so it looks like we're missing some kind of sync when flipping code segments
19:25imirkin: [148924.175013] nouveau 0000:02:00.0: fifo: read fault at 0019904000 engine 00 [GR] client 10 [PD] reason 02 [PTE] on channel 7 [007f905000 X]
19:25imirkin: old code segment: 19900000 (100000)
19:25imirkin: new code segment: 19a00000 (200000)
19:26imirkin: oh. lol. yeah. we're missing it bigtime.
19:27imirkin: hakzsam: you stick the SERIALIZE in there, but you don't wait for it to actually execute before nuking the bo. i think deleting the bo kills it immediately rather than on fence complete.
19:35imirkin: w00t! dirt rally loads now (at least gets to the "start" screen)
19:38karolherbst: I kind of expected some codegen CFG messup, but nice!
19:38karolherbst: ohh wait
19:38karolherbst: F1 might have a CFG messup, wrong game
19:40karolherbst: imirkin: uhm, by the way, is there an advantage if we mark less components of varying slots as used? like is there an advantage of having a 0x11111111 mask vs 0xffffffff in the shader header?
19:40karolherbst: I would assume perf reasons, but maybe you know more details
19:41pmoreau: imirkin: Nice post on Phoronix BTW! :-)
19:50imirkin: karolherbst: no clue
19:50imirkin: karolherbst: i would assume that there is
19:50karolherbst: I see
19:50imirkin: karolherbst: among other things, there's a max # of components that you can't go over
19:50karolherbst: right, I know about that one
19:50imirkin: i.e. you can only have 128 bits set in that map, but there are > 128 bits total
19:50imirkin: so ... you gotta watch out
19:51karolherbst: I was just wondering, because in that one tess test we set 124 bits, but we only need 31 actually
19:51karolherbst: it is an array of floats
19:51imirkin: right, and varying packing gets disabled
19:51imirkin: anyways, we might actually get the proper information via tgsi now
19:51imirkin: we didn't use to
19:51karolherbst: they aren't packed though
19:51imirkin: yea i know
19:51imirkin: coz packing gets disabled between tcs <-> tes
19:52karolherbst: I see
19:52karolherbst: I saw that I got to properly pack in other areas, like having 4 vec3 packed
19:53pmoreau: karolherbst: Dunno whether you looked at the logs, but I found https://github.com/ljbade/clcc for easily compiling OpenCL to PTX using the NVIDIA OpenCL compiler.
19:57imirkin: anyways, dirt rally seems to work fine now with my bindless impl. time to move on to the big leagues - dow3
20:12imirkin: well, this might come as some surprise, but an i7-920 with 6GB of ram and a GT 730 appears to be slightly under-spec for DOW3 :)
20:14imirkin: it does seem to basically work though
20:17karolherbst: well, I could take a look later
20:17airlied: imirkin: write a vulkan driver :-p
20:17imirkin: airlied: first i'm going to rewrite the GL driver
20:17imirkin: airlied: i'm still waiting on skeggsb for the UAPI for vk
20:18imirkin: (to be able to specify a VA for bos)
20:18imirkin: (or alternatively to be able to toggle bo's memory flags)
20:18imirkin: (actually that won't work - need to be able to place a BO at a specific VA)
20:19karolherbst: pmoreau: well, this would be an idea, just need PTX to nvir then
20:19imirkin: airlied: unrelatedly, any opinions about my drm_addfb woes for 30bpp?
20:20imirkin: basically i need 30bpp to be a different format than the one it picks now
20:20imirkin: it all worked fine before atomic since we didn't care about the drm formats
20:20airlied: imirkin: a flag seems easiest
20:20imirkin: ok, so just add a drm_driver->preferred_30bpp_format?
20:20airlied: prefer 30bppbgra
20:21airlied: or a format
20:21imirkin:hopes drm_driver gets calloc'd
20:26imirkin: karolherbst: 'bindless' branch on github - feel free to play with it
20:29karolherbst: imirkin: nice, thanks
20:29karolherbst: imirkin: did you try running hitman with it?
20:29imirkin: works mostly fine with dirt rally and dow3
20:29imirkin: only weird thing is the dirt rally loading screen
20:30imirkin: as if the texture wrap settings were off or something
20:30imirkin: i have an easy time blaming the game for that :)
20:30imirkin: i haven't tried hitman
20:30imirkin: i'll give it a shot...
20:31karolherbst: imirkin: ohh by the way, somebody told me a story about some fancy compute shader abuse some games might start to do: putting all scene post processing into compute shader and run it alongside the rendering of the next frame :)
20:32imirkin: should be fine... or you mean in a diff context?
20:33Manoa: ben will keep working on the driver even after leaving the company ? btw thank for update for r600 dave
20:33karolherbst: same context I think, but I guess multithreaded? not quite sure, I could ask about more details
20:33airlied: imirkin: so how is the addfb user supposed to knkw the layout btw?
20:34karolherbst: Manoa: huh? did I miss something?
20:34imirkin: airlied: they don't. cool, huh?
20:34imirkin: airlied: if they cared, they'd use addfb2
20:34imirkin: if they don't care, they're xf86-video-nouveau and they know what the kernel driver does
20:35imirkin: karolherbst: i get a ton of this with hitman: [153101.024758] nouveau 0000:02:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 000e [OOR_ADDR]
20:35karolherbst: I know
20:35imirkin: OOR_ADDR means ... i forget
20:35karolherbst: you have to enable bindless in the settings though
20:35airlied: imirkin: just makenouveau ddx use addfb2 :-)
20:35karolherbst: this is the one TSC/TIC overflow
20:35imirkin: iirc it means that you're reading past the end of a constbuf
20:35airlied: not.like 30bpp users are knocking down doors here :-)
20:36imirkin: airlied: no amount of code i write now will cause older userspace to change =/
20:36karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/d12d1cdbd3f26f4f9437bc4d03e4870279a83354 and https://github.com/karolherbst/mesa/commit/4e4aa97982654db815be252cdb00ec4f661f2f8c
20:36imirkin: airlied: anyways, yeah, i could flip it to use addfb2. i just didn't think that was a great solution.
20:37karolherbst: imirkin: and some issues go away by forcing an ATI gl vendor...
20:37imirkin: airlied: since it works as-is with 30bpp
20:37karolherbst: but I would be interested if bindless makes a difference
20:37imirkin: all the redmask/etc stuff is set up correctly
20:38imirkin: karolherbst: yeah ... that makes no sense :) doesn't mean it doesn't happen ... :)
20:38imirkin: karolherbst: would require proper investigation
20:39imirkin: anyways, feel free to test it out with bindless
20:41imirkin: actually i'll just try it
20:43imirkin: nve4_launch_grid:752 - Failed to launch grid !
20:43imirkin: interesting, i get a bunch of those
20:45imirkin: airlied: btw, how much do you know about 30bpp?
20:46imirkin: like ... let's say i have a digital connection ... do i need to pick a different mode? how does it know it's 10bpp of depth per channel? or does it just truncate to 8 bits unless it's some special thing?
20:46imirkin: [e.g. the hdmi "deep color" thing in the infoframe or whatever]
20:46Manoa: I thought I read somewhere ben leaving red hat I can't find it now, mybe I was wrong. I suppose ben programming the driver and his work is payed by red hat ? and you guys also ? I think that's nice that companies with many money investing into open source
20:47imirkin: Manoa: i know ben moved physically from place to place but i haven't heard of him leaving RH.
20:48imirkin: Manoa: RH and other companies invest fairly substantially into open-source software. (RH may be the most prolific, not sure. i doubt it's properly accounted anywhere.)
20:49Manoa: I wonder though, if any of the companies that are big like RH, could, in addition to investing into open source programmers, had some money left to "buy out" and change some of nvidea's policy to give some documentation
20:52Manoa: nvidea is going to lose in the end, sooner or later (not only because of walled garden spyware milking stations like W10) open source will be good also for game production, it's just that right now windows have the most programmers and bill gates have the most money
20:57Manoa: I wanted to test the code you offered me before ilia and now I also want to test your changes on my 580 but the card is not plugged and I can't reboot with so many x264 instances running :x
21:00Manoa: ...and by the time nvidea understand that open source would been good for them, AMD will already have (if not already ?) huge advantage in linux
21:55RSpliet: imirkin: ftr, the card infinity0 owns is the one I had for a while. Traces should already be in the usual places :-)
21:55pmoreau: karolherbst: Yeah, PTX to NVIR would be interesting, especially for a CUDA implementation.
21:55imirkin: RSpliet: literally the one you had, or one just like it?
21:55RSpliet: literally the same one
21:56RSpliet: he lended it to me for a while :-)
21:56karolherbst: pmoreau: well, I would still prefer to convert PTX to spir-v or nir or whatever. I think nir would be much easier, because PTX is pretty simple
21:56imirkin: hehe ok
21:56karolherbst: I wouldn't want to convert it directly, because I would want to have PTX support for all mesa drivers :)
21:56karolherbst: if we would work on that in the first place
21:57imirkin: karolherbst: ptx enables you to do all kinds of stuff that is very nvidia-specific
21:57pmoreau: Let’s get at least one compute API working on Nouveau (not counting GLSL compute shader)
21:57karolherbst: I see X to nvir directly as an optimisation, which we can do later as well
21:58imirkin: karolherbst: so just get everything in tgsi and move on :)
21:58karolherbst: there are more relevant drivers supporting nir than tgsi
21:58karolherbst: and until we get proper compute support, we still need 1y+
21:58karolherbst: so even AMD could do it by then
21:58karolherbst: or they stick with llvm, I don't care
21:59karolherbst: or somebody could try PTX to TGSI
21:59karolherbst: personally I just think that in long term, NIR allows us to support more drivers in the end, that's all
21:59karolherbst: and get better community support for various things
22:00karolherbst: if we do 4 different X to nvir, we have to maintain it, if we do X to nir to nvir, we end up only having to support nir to nvir
22:01imirkin: and who supports X to nir?
22:01imirkin: it'll all fall on us anyways.
22:02karolherbst: some driver might be interested in several X to nir things
22:02karolherbst: maybe not
22:02imirkin: majority of development power for nir comes from intel, and they outgun us like 50:1
22:03karolherbst: well, if they want to support PTX and help us out with PTX to nir, then I don't see the problem :)
22:03imirkin: which means we're going to be in a permanent state of playing catch-up
22:03imirkin: yeah they don't give a shit about that
22:03imirkin: they've got their hands full of other things
22:03imirkin: like bringing up genN+1
22:03karolherbst: well, I don't know
22:03karolherbst: I didn't ask
22:03imirkin: and making progress on their infinite bug backlog
22:09karolherbst: imirkin: any idea what are wrong with the arb_shader_image_load_store.atomicity tests? I got them to pass with nir, but 7/8 fail with TGSI
22:09airlied: imirkin: my 30bpp sucks, but i think you have to setup the encoders as well as crtc
22:09karolherbst: ohh wait, silly me
22:09imirkin: airlied: i mean like once it leaves the card
22:09airlied: to encode the link bit depth
22:09karolherbst: those are the ones which failed due to GL_OUT_OF_MEMORY and issues on my last tgsi run
22:10airlied: and thsn infoframes
22:10imirkin: airlied: i don't know that much about like DVI
22:10imirkin: beyond it being "digital"
22:10imirkin: but presumably it sends a sequence of bits that are then assembled into colors on the display
22:11imirkin: and so how does the display know it's 30bpp vs 24bpp?
22:11imirkin: or is it just not possible with DVI, you have to use hdmi to get it, by setting an appropriate bit in the infoframe?
22:12airlied: pretty sure hdmi only
22:12imirkin: ah ok, that makes sense then
22:12airlied: and it uses infoframes
22:12imirkin: right, so then it knows if it should look for 24 or 30 bits
22:13airlied: i think yoy can do 30 bit over dvi
22:13airlied: its just non standard hacks
22:14imirkin: hm ok
22:15imirkin: "DVI will not natively support 30-bit deep color. It is possible to enable 30-bit color
22:15imirkin: over DVI using device specific pixel packing method. In this approach, off screen
22:15imirkin: buffers are used for rendering at a deep color value and a fragment shader is used to
22:15imirkin: implement the monitor-specific pixel packing."
22:16imirkin: this is from some nvidia whitepaper from 2009
22:17karolherbst: sounds messy
22:18karolherbst: I am sure we would also need some kind of list where there is a mapping of display => pixel packing format?
22:18karolherbst: I don't see how the display is able to say anything about that anyway
22:19imirkin: yeah, it'd have to be hacky like airlied said
22:19imirkin: so this is basically a DP + HDMI feature
22:19imirkin: (apparently there's some way to indicate it in DP as well)
22:22airlied: dp has infoframes
22:22imirkin: karolherbst: btw, i'd appreciate it if you could give bindless a shot - i just pushed out a very minor update. it seems to work for me, both dirt rally and dow3.
22:22imirkin: karolherbst: but i have shit-for-hardware so perhaps something pops up on a beefier gpu like yours
22:23imirkin: airlied: right ok :) so basically no infoframes = world of pain for 30bpp
22:26imirkin: airlied: i'm mostly focused on the software end of 30bpp (i.e. having the proper format/etc support) rather than actually making it show up on an appropriate monitor
22:26imirkin: although i do have a deep-color-capable tv
22:26Manoa: I was just thinking, I have many 8bpp games, it would be nice to play them at 10bpp, you think up convertion from 8 to 10 in the driver, using say shaders can give higher quality ?
22:26imirkin: but you never know what this means in practice
22:26airlied: you really want fp16 scankut anyways :-)
22:27imirkin: airlied: that's supported since G80
22:27imirkin: there's no DRM_FORMAT for it though?
22:27imirkin: although iirc there were patches, just not-landed
22:27imirkin: or not-in-master? dunno.
22:44airlied: yeah not sure where they went yrt
22:44airlied: ill start caring about hdr nrxt week
22:45airlied: got a shiny dell hdr10 monitor
22:46imirkin: airlied: nice :)
22:47karolherbst: imirkin: yeah, I will try to try it out until the weekend or earlier
22:48Manoa: it would be nice to have 10 bit games
22:50imirkin: karolherbst: cool thanks. i think dow3 will always just use it. it's a massive game though.
22:50karolherbst: yeah, no worries about size
22:50imirkin: karolherbst: for dirt rally and others, you have to flip something in ~/.local/share/feral-interactive/the-game/preferences
23:02Simber: I think I might have found a bug in nouveau
23:02Simber: How would I go about reporting this
23:02Simber: as a linux noob
23:03imirkin: describe it here, making sure to mention what hw you have and how you encounter it
23:04imirkin: next steps will often involve filing a bug at bugs.freedesktop.org. but perhaps i can save you the trouble.
23:05Simber: Basically I can't boot when I have my vive's HDMI connected
23:05Simber: using latest mint with 1070 and i5 3570k
23:05imirkin: do you get an oops or other message in dmesg?
23:06Simber: If you give me 5 min I'll check
23:06Simber: it just hangs on boot though
23:06imirkin: what hangs?
23:06Simber: the entire system
23:06imirkin: how do you know?
23:06Simber: actually I still get a boot sound
23:07Simber: but no video
23:07imirkin: do you have a second computer?
23:07Simber: if I disconnect the vive and restart its fine
23:07imirkin: boot up with the vive connected and then ssh in from the second comp
23:07imirkin: and check what's in dmesg
23:07imirkin: my guess is that it's coming up just fine, just no video
23:08imirkin: [make sure your target machine is configured to allow ssh and whatnot]
23:10Simber: I'll do that now, Simber_v2 is my lapto
23:12Simber_v2: I guess the vive is doing some weird stuff though cause it doesn't show up as a display
23:13imirkin: might be expected...
23:13imirkin: do you, by any chance, see a console on it?
23:13imirkin: (a highly distorted one)
23:14Simber_v2: I haven't thought about looking at it yet
23:14imirkin: although all screens should be showing stuff in that case
23:14imirkin: my guess is that nouveau dies in modesetting
23:15imirkin: as a result of something unexpected. i don't think any nouveau developers have played with a vive yet.
23:15imirkin: and airlied's hogging his :)
23:15Simber_v2: That took along time to timeout, damn
23:16Simber_v2: ok, just pluging the vive in while it's running causes it to freak out
23:16imirkin: also note that 1070 is pascal which isn't the best-supported hw on nouveau
23:17imirkin: Simber_v2: ok, so then boot without the vive
23:17imirkin: ssh in
23:17imirkin: run 'dmesg -w'
23:17imirkin: and then plug it in
23:17Simber_v2: it caused screen one to distort alot and screen 2 stopped reciving input
23:18imirkin: well - the way the vive works is actually you have to send it highly-distorted images in order for them to appear correctly
23:18imirkin: so if you send it a regular image, it'll look all weird
23:20Simber_v2: Thats a paste of dmesg
23:20Simber_v2: the error starts on line 327
23:20imirkin: do you have some kind of super-debug option enabled for nouveau?
23:21imirkin: [ 182.268370] nouveau 0000:01:00.0: disp: 0x6269: INIT_GENERIC_CONDITON: unknown 0x07
23:21imirkin: that's fine
23:21imirkin: the lines after -- not fine.
23:21imirkin: so that's a modeset failing
23:21Simber_v2: Its showing the vive in the displays list too
23:22Simber_v2: it's also showing my other monitor which is nolonger reseving input
23:22imirkin: file a bug at bugs.freedesktop.org xorg -> Driver/nouveau, and include that error (attached), and also attach /sys/class/drm/card0-HDMI-A-1/edid (or whatever the right connector for the vive is)
23:24imirkin: unfortunately i'm not sufficiently well-versed in reading those modeset failures
23:24Simber_v2: I got another spew of errors when trying to move display postions
23:25Simber_v2: I'll attach both of those and that file in a bug report
23:27Simber_v2: I take it edid isn't meant to be human readable
23:28imirkin: no, it's just data
23:28imirkin: there are programs that can parse it
23:28imirkin: should be 128- or 256-byte blob
23:29imirkin: (maybe even bigger for vive... recent stuff has all sorts of extension stuff in there)
23:39Simber: Where should I upload the edid
23:40imirkin: as an attachment in the bug
23:40Simber: nvm, an attachemnt
23:40imirkin: you can only have one attachment when first creating it
23:40imirkin: but you can add more after it's created
23:40Simber: Im not used to sites allowing sttachments like that now a days
23:42imirkin: yeah, blast from the past :)
23:42imirkin: back when you could actually do things on the internet
23:42imirkin: instead of just watching advertisements and buying things
23:43Simber: Im too young for most of those days, I only caught the end of them
23:43Simber: I've hardly used IRC tbh
23:45imirkin: you'll get old too. just give it time.
23:52Simber: I've submitted the bug
23:53imirkin: please attach the messages - pastebins go away after a while
23:53imirkin: for a self-described noob, you sure file some very cogent bug reports
23:55Simber: The entire pastebins?
23:55Simber: The first one is almost 1.9k lines
23:56Simber: Or should I just attach them as txts
23:57imirkin: attach a plaintext file with the various contents
23:58imirkin: we live in the future
23:58imirkin: so storing a few kb in a bug is no big deal
23:59imirkin: excellent thanks