00:06imirkin: pmoreau: i guess one thing to try would be to do the same ridiculous thing nvidia does for setting those (i.e. via a macro). but i can't imagine why that would be... it'd have to be a pretty significant hw bug
00:07imirkin: it feels more likely they want to have an easy way of flipping polygon offsets off globally if there's no depth buffer bound or something
00:32Horizon_Brave: evening everyone
01:13dboyan: imirkin: I heard there is a fix for demmt's GET_CHIPSET for newer blob?
01:54imirkin: dboyan: yeah, so... need to send it an extra uint in nvrm_mthd.h::nvrm_mthd_subdevice_get_chipset
01:54imirkin: (in mmt)
01:56dboyan: that's cool
01:57imirkin: we need to test whether that breaks mmt on older blob
01:57imirkin: so if you have that set up, it'd be great to check
01:59dboyan: unfortunately I don't have one currently.
02:02dboyan: imirkin, what does the 'syms' in nv50_ir_prog_info do? why do we have to store that for compute program?
02:03imirkin: i think it was for function linkage? not 100% sure. i don't think anything uses that today.
02:03imirkin: [double-check whether i'm lying...]
02:04dboyan: that's just another frustration with "what to store in shader binary"
02:05imirkin: well, if nothing uses it, you can ignore it
02:05imirkin: maybe stick a assert(syms==null) and move on
02:06dboyan: i guess it's used somewhere, however
02:07dboyan: used in nvc0_program_symbol_offset, which is called by nvc0_launch_grid for example
02:08imirkin: mmmm... but is it *really* used?
02:08imirkin: if it's never set ...
02:08imirkin: thing is, there's a bunch of code around for half-supported use-cases. like early opencl attempts, etc
02:09imirkin: i suspect that code may be specific to those.
02:09dboyan: It's used to convert pipe_gride_info.pc to another value and fill it into CP_START_ID
02:09imirkin: well, for compiled compute kernels, you need to be able to have multiple entrypoints
02:09imirkin: so i think that's why it's there
02:09imirkin: (with OpenCL)
02:10imirkin: obviously with GL, there's nos uch thing
02:11dboyan: I'll test and see later
02:12dboyan: It seems radeonsi used tfb state as part of cache key, I think this provides a solution to the tfb issue we talked about earlier
02:13imirkin: for other reasons
02:13imirkin: the tfb state doesn't change the compiled code
02:13imirkin: it's only there to avoid revalidating all the tfb state on program switches
02:15AndrewR: Hi all! I tried patch from https://lists.freedesktop.org/archives/mesa-dev/2017-March/147578.html and it seems to work! At least wine + 3Dmark2001SE created few cache entries, and some stalling at first bench (Car Chase) is gone
02:16dboyan: imirkin: yeah pipe_grid_info.pc is 0 for opengl, st/mesa never set that
02:17imirkin: AndrewR: cool, thanks for testing!
02:17imirkin: dboyan's working on a bigger better version of that patch now
02:18AndrewR: imirkin, ok, it seems whole shader chache infrastructure will be reworked soon , anyway (looking at mesa ML patches)
02:18dboyan: yeah, this one is a prerequisite though
02:19AndrewR: imirkin, I tested on top of commit a01a10421607ec19ee3ed01ab8e6062499aaec92 ("relnotes: [swr] note addition of gs, increased llvm requirement")
02:21dboyan: AndrewR: I don't think the infrastructure change will touch the API it exposes anyway. So most probably it will work as it is now.
02:21dboyan: And thanks for the testing :)
02:22AndrewR: dboyan, I can try few more things (unigine demos), but they might hang ...
02:24dboyan: well, i guess we have to ensure that it doesn't cause more hangs :)
02:28imirkin: AndrewR: unigine demos hang on your gpu? that's unexpected =/
02:28imirkin: is that the G92?
02:29imirkin: dboyan: you probably saw, but i pushed a fix to properly process the -m flag for demmt. so now demmt -m 108 should work for you.
02:31imirkin: RSpliet: should i expect your tree to work on a GF108 + DDR3 vram?
02:38imirkin: Lyude: ping about nouveau 1.0.14 tarball
02:38dboyan: imirkin: thanks, it works for me now. i was using a hack locally. the fix now is definately better than mine
02:39imirkin: well, my fix is still a giant hack - you can read the commit message
02:41AndrewR: imirkin, not just unigine, I think Xonotic at ultra and _some_ maps hang too
02:42imirkin: is it the tesla CACHE_ERROR thing?
02:43AndrewR: just hanged my GPU (and whole machine) again. Unigine tropics 1024x768 no AA - runs ok, attempt at setting 8AA resulted in hang. 3Dmark201SE was running fine with 8x antialiasing..and Unigine heaven tend to hang w/o AA on any resolution more than 640x480 windowed ...I still tend to blame PSU ....
02:43AndrewR: imirkin, hard to say, i'll check logs, but apparently those hangs leave nothing there, at least with def. debug level
02:48AndrewR: imirkin, no, just bunch of 0s between last entry about reclocking and msg from new boot. (on ext4)
02:56AndrewR: dboyan, this hang was around since I changed motherboard-cpu-ram-psu ... so, it was not new hang due to your patch
02:57imirkin: hmmm.. sad.
06:45Weaselweb: Hi, I found a regression in v4.10. I think I properly bisected it back to commit 839ca90 ("drm/nouveau/kms/nv50: transition to atomic interfaces internally", 2016-11-04)
06:46Weaselweb: my observation: when screen goes into power-off (DPMS) it happens that after wakeup the login-screen (sddm) or screensaver (plasma) is not updated at all. I dont see any input happen, although the mouse cursor is still moving while I also can switch VTs
06:48Weaselweb: starting with this commit I also get those errors: http://pastebin.com/iuVp18dc. Dunno if this is related
06:48Weaselweb: my video card: 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
08:54pmoreau: imirkin, dboyan: Yes, it is indeed used with OpenCL, when you have multiple kernels in your program, so please don’t remove it! O:-)
08:56pmoreau: Weaselweb: Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=99922, which should be fixed by using xf86-video-nouveau 1.14, or applying the patch found in the bug report.
08:58dboyan: pmoreau: I'll try not to remove that in the final form, but I guess I'm going to remove it for local developing at the moment
08:59dboyan: to make things simple
09:00pmoreau: What are you currently working on? Last I remember was the 64 bit operations rcp and rsq
09:01dboyan: on-disk binary shader cache
09:01pmoreau: Ah, right! :-)
09:17Weaselweb: pmoreau: nice, I give xf86-video-nouveau 1.0.14 a try
10:41RSpliet: imirkin: No, there's no DDR3 script written up, just GDDR5
11:58dboyan_: karolherbst: I saw you asking for mmiotrace of the blob. Is it okay to just trace things like glxgears?
12:01karolherbst: dboyan_: yes, as long as nvidia clocks to max at least once
12:04dboyan_: I'll try after I get access to that machine
12:08karolherbst: dboyan_: I doubt I will be able to do anything for nouveau until the weekend of next week or so. If you have it just ping me with a link to download it and I will look into whenever I have time
12:09karolherbst: dboyan_: but you could try something else as well
12:09karolherbst: dboyan_: trace nvidia. open nvidia-settings, set the preferred performance mode to max. Then it should clock to the "base" clocks. then start some OpenGL application, so that the driver raises the clocks to the max possible
12:10karolherbst: dboyan_: what I need is tha differences between the different clock states to figure out what the exact changes are
15:04dboyan_: karolherbst: I tried to mmiotrace blob, and it's getting "failed to copy vbios to system memory" error. Same as what's happening my pascal system. But I bet it was okay weeks before
16:35nyef: Just tested: MCP89 (Mac Mini 2010), HDMI and mDP->HDMI connections, audio output. If the displayport connector is in use, playback to the HDMI connector does not work.
16:35nyef: Playback to the DP connector does work, though.
16:36imirkin_: that makes ... sense
16:36imirkin_: i don't have a complete picture on how the whole hda codec thing works
16:39nyef: Guess this means that I should try to find some way to test with the dual-DPort card that I have.
16:39imirkin_: you might want to ask some amd/intel people about how this stuff is meant to work with sane/documented hw
16:41nyef: Or just table the issue for the time being.
16:45nyef: I mean, I already knew that the HDMI port worked. And it's good to have re-confirmation that the DPort->HDMI works. And that's already an improvement over 4.9, and I rarely run more than the one screen on this box anyway.
16:45nyef: ... Though now I'm wondering what the other ELD is for, and I suspect that it's for the straight DP rather than the DP->HDMI connection.
16:51nyef: Hrm, no, The straight DP connection is still eld#6.
16:51nyef: Err... eld#4.0, sorry.
16:51imirkin_: i wouldn't be surprised if we were configuring some of the eld bits slightly wrong
16:51imirkin_: it was all based on a very small amount of RE, just enough to get the thing going
16:51imirkin_: audio over HDMI/DP is a fairly rarely-used feature
16:52imirkin_: esp among developers
16:52nyef: Especially these days, with everyone using pulseaudio->bluetooth. d-:
16:53imirkin_: well, dunno about pulseaudio, but yeah. i'm actually thinking of picking up a pair of bluetooth headphones (with passthrough cable capability)
16:53nyef: (We'll leave aside the pain in the ass it is to switch between stereo output and mono output but having working input on a bluetooth headset in linux.)
16:54imirkin_: well, with A2DP i think it's gone beyond mono...
17:14nyef: The problem isn't so much stereo vs. mono, it's switching profiles so that you have the mic or not.
17:39nyef: ... And DPort HPD is still not working right on this machine.
17:49nyef: Attempting to write to /sys/class/drm/card0-DP-1/status causes a write error, but causes the HPD to partly kick in, and the first time I tried this it picked up the console display mode and mirrored the other panel, but the second time it /didn't/. The computer says that it's connected, and X seems to behave as though there's a legit framebuffer there, but the display doesn't see a signal.
17:53nyef: ... And I managed to lock it up, somehow. Lovely.
17:57karolherbst: dboyan_: oh no :( again such random issues
17:58imirkin_: there's apparently some issue with 4.10 and multi-display things
17:58nyef: Okay, power up on HDMI, no DP. Start X. Open monitor control panel. Connect DP. Nothing happens. Hit "Detect monitors", DP fires up. Unplug DP, DP disconnect detected. Re-connect DP, nothing happens. Hit "Detect monitors", DP fires up. Unplug DP, /system locks up/.
17:58imirkin_: nyef: https://bugs.freedesktop.org/show_bug.cgi?id=99841
18:00nyef: Hrm. Would this explain the same scenario occurring without X, presuming that a write to the "status" file for the connector forces HPD?
18:00imirkin_: i have no clue.
18:00imirkin_: merely pointing at a potentially-relevant bug
18:00imirkin_: try reverting 865afb11949e5bf4bb32d9a2aa9867c1ac4d8da0 and see if that makes it all better
18:02nyef: Hrm. Doesn't seem likely, as it locks the system totally (not even network access available), whereas these reports seem to have a recovery via switching to the VT and restarting X.
18:03imirkin_: ah ok
18:09nyef: There might be a single bug here, or possibly multiple bugs "stacked one on top of the other like griddle-cakes", but the first thing to investigate, presuming that I get around to it, is the HPD not working automatically.
18:10imirkin_: so... 4.10 introduced atomic
18:10imirkin_: so you should def try pre-4.10 and post-4.10
18:10imirkin_: as separate things
18:10imirkin_: since that had a big effect on the display code
18:15nyef: Good point.
18:18nyef: But I also have to do cost-benefit analysis on continuing to work on this. It's an HPD issue, but I normally don't hotplug this machine. There's an HDA issue, but it only kicks in on a multi-display situation, and I normally don't multi-display this machine. Fixing them would be nice, but I have limited time and energy, and the stereographic stuff to work on as well.
18:21nyef: Plus there's all of the non-nouveau things to work on.
18:22imirkin_: a veritable quandry
18:30imirkin_: RSpliet: btw, now that i have a fermi plugged in ... what was the issue you were having?
18:31imirkin_: (in addition to the INVALID_VALUE stuff... iirc you said there was some rendering fail)
18:59nyef: Okay, 4.4.39 doesn't lock the system on repeated hotplug, but does still fail at automatic HPD.
19:00nyef: Which does make this at least two bugs.
19:00nyef: At least one of which is a regression.
19:01imirkin_:still needs to figure out wtf is up with the pci nv44a
19:01imirkin_: allegedly it worked in 3.13
19:09nyef: So, further questions on HPD: Does it work with the HDMI port? Does it lock up with repeated HPD on the HDMI port? Is it specific to the MCP89, or does it also happen with other DISPs?
19:10nyef: And, on another front, where did I leave off with the stereo stuff? (-:
19:17mslusarz: imirkin: you probably could inject 2 GET_CHIPSETs with different sizes and it will work with both old and new blob versions
19:18imirkin_: mslusarz: hm, good point. will take a minor demmt update probably, but doable
19:18imirkin_: do you remember the blob being finicky about being given buffers that were too big?
19:19mslusarz: it depends if buffer size is encoded in ioctl/method/whatever number
19:20mslusarz: if it's not blob shouldn't care
19:21mslusarz: but I misremeber things, so...
19:21mslusarz: I might misremeber*
19:25imirkin_: yeah, definitely needs testing
19:56nyef: 4.9.6, GF119, DPort HPD: Also non-functional.
20:05imirkin_: oh, hm - there were a couple of minor-seeming fixes to i2c logic in skeggsb's tree
20:05imirkin_: https://github.com/skeggsb/nouveau/commit/406d99ec279ac67dc302cccb236f6fca182c4843 + https://github.com/skeggsb/nouveau/commit/79ce00eaa49d76e435f432a50cb0d4a9b1182aa6
20:06imirkin_: i believe in response to some DP compliance work, but who knows, perhaps it affects your situation
20:11nyef: Hrm. Maybe.
20:11nyef: Currently trying to get things set up so that I can do the basic RE for HDMI 3D on the last two DISPs.
20:11imirkin_: probably a more enjoyable use of time than debugging hard hangs :)
20:13nyef: Not really. It's a lot of rsync over a network with obnoxious levels of packet loss.
20:20karolherbst: imirkin_: do you know any other place I have to adjust for variable TIC/TSC sizes? https://gist.github.com/karolherbst/40743005971d9e5dd061bd71537337db
20:21imirkin_: *32 seems low
20:21imirkin_: er wait, no, that's right
20:21imirkin_: also, not that it matters, but
20:21imirkin_: screen->tsc.entries = screen->tic.entries + NVC0_TSC_MAX_ENTRIES
20:21imirkin_: that should be TIC_MAX_ENTRIES
20:21karolherbst: ohh true
20:22imirkin_: you also need to...
20:22imirkin_: hm, no. that looks taken care of...
20:23karolherbst: something is still odd though, that's why I am asking
20:23imirkin_: i was going to say, update the lock stuff. but that's keyed off the max entries defines
20:25imirkin_: ret = nouveau_bo_new(dev, NV_VRAM_DOMAIN(&screen->base), 1 << 17, 1 << 17, NULL,
20:25imirkin_: might want to double-check that that's big enough
20:25imirkin_: looks like 128KB, or 64K each. i think that's off by one, no?
20:25imirkin_: one of those needs to be 1<<18
20:25imirkin_: (the non-alignment one)
20:26karolherbst: which is the second I guess
20:26imirkin_: or you could look at the docs :p
20:26karolherbst: the other one has 1 << 17, 1 << 20
20:26karolherbst: so would be odd
20:26imirkin_: int nouveau_bo_new(struct nouveau_device *, uint32_t flags, uint32_t align,
20:26imirkin_: uint64_t size, union nouveau_bo_config *,
20:27imirkin_: the 1<<17 alignment is so it gets large pages (128K each)
20:27nyef:remembers having less address space than that page size.
20:27imirkin_: although they're configurable and can be made 64K each
20:28imirkin_: nyef: 16-bit real mode is fun =]
20:28nyef: The 6502 CPU is fun. d-:
20:29imirkin_: or what was that intel pic?
20:29karolherbst: imirkin_: okay, that's better, but still wrong
20:29nyef: 16-bit real mode gets you a full meg of address space, or a meg plus just under 64k on a 286.
20:29nyef: (Or any later CPU, really.)
20:29karolherbst: mainly colors are wrong
20:30imirkin_: ah right. 8051.
20:32nyef: Heh. The 3D Vision IR emitters are 8051-based.
20:33imirkin_: nyef: yeah, the extra 4 bits from the segment register are nice.
20:33nyef: (Okay, they're EZ-USB-FX2-based, but that's 8051-based.)
20:35karolherbst: imirkin_: any other idea? I currently looks like if somebody turned up the contrast by a lot
20:37imirkin_: karolherbst: sorry, no
20:37imirkin_: iirc we don't have a mechanism for evicting things from the tic
20:37imirkin_: and txc lists
20:37imirkin_: i dunno. maybe we do. i really don't remember.
20:38imirkin_: perhaps the locking goes nuts somehow
20:42karolherbst: in nvc0_tex is also some tic stuff
20:44karolherbst: but that also looks fine? or not
20:45karolherbst: ahhh "65536 + tsc->id * 32" yeah, that looks also wrong
20:54karolherbst: I think I got everything no
20:54karolherbst: 65536 was really just used for the tsc offset, how handy
20:57karolherbst: \o/ it works
20:57karolherbst: now I can set the tic/tsc size with those constants :)
20:58karolherbst: only for nvc0, but I think this is fair
20:58karolherbst: the crash is gone?
20:59karolherbst: yay, let's wait until the run is finished and do more
21:02karolherbst: imirkin_: I hope I didn't mess something up here? https://github.com/karolherbst/mesa/commit/fe8f3c8842e81aa2a0db61ff41dca45f0542d3f6
21:03imirkin_: + ret = nouveau_bo_new(dev, NV_VRAM_DOMAIN(&screen->base), 1 << 17, NVC0_TSC_MAX_ENTRIES << 6, NULL,
21:03imirkin_: is that right?
21:03imirkin_: i think you want NVC0_TIC_MAX + NVC0_TSC_MAX
21:03karolherbst: and then << 5 ?
21:03imirkin_: oh, you do *2
21:03imirkin_: right. wtvr.
21:03karolherbst: they could have different values, couldn't they?
21:04imirkin_: anyways, that all seems reasonable.
21:04imirkin_: yeah, they could
21:04imirkin_: they just don't, so won't immediately have a negative effect :)
21:04karolherbst: okay, so I change that one part into + with << 5 then
21:05karolherbst: okay I still get crashes though. But I hope at least that invalid write is gone now....
21:07imirkin_: that's not a permanent solution
21:07imirkin_: the game creates and uses a ton of textures
21:07imirkin_: we need to have a more dynamic handling of that.
21:08karolherbst: I highly doubt I fixed those invalid writes though
21:14karolherbst: imirkin_: yep... something is wrong with the locking code
21:15karolherbst: put in asserts: nvc0_screen_tic_alloc: Assertion `i < NVC0_TIC_MAX_ENTRIES / 32' failed.
21:15karolherbst: it is 128
21:16karolherbst: off by one issue somewhere?
21:16karolherbst: screen->tic.next is 129
21:16karolherbst: ohh makes sense
21:16imirkin_: no, it's just run out of room i guess.
21:16karolherbst: you do that mod and div thing there
21:17karolherbst: to map values down to a 0-127 range
21:17karolherbst: and this has a bug
21:17karolherbst: while (screen->tic.lock[i / 32] & (1 << (i % 32))) i = (i + 1) & (NVC0_TIC_MAX_ENTRIES - 1);
21:18imirkin_: so it's an infinte loop if the table is filled up...
21:18karolherbst: NVC0_TIC_MAX_ENTRIES is much higher than the table is big
21:18karolherbst: NVC0_TIC_MAX_ENTRIES - 1 is 2047
21:18imirkin_: 4095 with your change.
21:18karolherbst: okay, so this code is wrong
21:18karolherbst: it's wrong anyway
21:18imirkin_: the code is wrong??
21:18karolherbst: cause i can get bigger than the array is big
21:18imirkin_: seems right...
21:19karolherbst: the array is NVC0_TIC_MAX_ENTRIES / 32 big
21:19karolherbst: should I remove that / 32? :D
21:19imirkin_: i is the logical lock index
21:19imirkin_: each entry in the array holds 32 locks
21:20imirkin_: i ends up being the tic/tsc id.
21:20imirkin_: (still don't see the issue)
21:20imirkin_: i'm tired, so perhaps i'm missing it.
21:20karolherbst: i can get bigger than the array
21:20karolherbst: resulting in out of bound writes
21:20imirkin_: what seems to be the problem with that?
21:20karolherbst: screen->tic.entries[i] = entry;
21:20urmet: what to think about this? http://pastebin.com/Ba0NYx7W
21:20karolherbst: ohh wait
21:20imirkin_: oh. THAT is bad.
21:20imirkin_: that's entries
21:20imirkin_: not locks
21:20karolherbst: my mistake
21:21karolherbst: still have that invalid write of 4 there
21:21imirkin_: urmet: are you booting this box in some way that it's not designed to be booted?
21:21karolherbst: nv50_tic_entry(screen->tic.entries[i])->id = -1;
21:22urmet: imirkin_: not that i know of. cold boot, initramfs, nothing special
21:22imirkin_: karolherbst: again, what seems to be the problem? that indicates it's unallocated.
21:22imirkin_: urmet: i meant more like forcing some box to boot via e.g. efi when it's not supposed to
21:22imirkin_: or vice-versa
21:22karolherbst: I don't know, valgrind says there is one
21:22imirkin_: is this a laptop, something else?
21:22imirkin_: (it must be a laptop)
21:22urmet: imirkin_: laptop. and I've always used efi booting
21:23imirkin_: karolherbst: perhaps something freed the underying texture view? that'd be sad. but shouldn't happen...
21:23imirkin_: urmet: is this a new issue?
21:23karolherbst: I changed my asserts and removed the / 32
21:23karolherbst: maybe it gets hit
21:23karolherbst: ohhhhhh wait
21:23karolherbst: this would result in an invalid read as well
21:24urmet: imirkin_: new-ish. I don't usually notice nouveau not working, so it might be broken for some time for me
21:24imirkin_: has it ever worked?
21:24imirkin_: [with nouveau]
21:24imirkin_: and what kernel is this?
21:25urmet: i get this error with at least 4.10.1 and 4.11.0-rc2
21:25imirkin_: ok. we've been fiddling with acpi bios stuff a bit... mind booting with nouveau.debug=debug
21:26imirkin_: (and/or loading nouveau with that)
21:26urmet: just reloading the module without rebooting would give usable information?
21:26nyef: Where's the start of the HDMI space for GF119?
21:26imirkin_: as long as that parameter is set as a module arg
21:26imirkin_: nyef: check hdmigf119.c :p
21:27nyef: I did, but it uses composite offsets (base + offset_within_space) and then applies the per-head offset (which is head_number * 0x800).
21:28imirkin_: looks basically like 616700..800 + n*0x800
21:29imirkin_: although ... odd that it's head offset and not sor offset. wtvr. i can barely remember what those things are.
21:29nyef: Except that there's existing precedent for it taking up more than a mere 64 words, so I need to cover the entire space, and I don't know where the space starts.
21:29nyef: And sometimes they can start on weird boundaries, can't they?
21:30imirkin_: nyef: https://github.com/envytools/envytools/blob/master/rnndb/display/g80_pdisplay.xml#L892
21:30imirkin_: no clue how accurate that is. might be for gf100 only
21:31imirkin_: either way, it'll usually be packed in close together.
21:31nyef: ... 0x500 from the SOR base, 0x800 per stride, length 1? But I know full well that there are at least two entries.
21:32urmet: imirkin_: http://pastebin.com/Fjb8MuwE
21:33imirkin_: urmet: sounds like it didn't get the debug thing
21:33imirkin_: also ... i guess we fail at msi on teardown. oops.
21:33nyef: ... And the SOR regs as a whole are *also* 0x800 bytes? What?
21:33imirkin_: just coz stride = 0x800
21:33karolherbst: imirkin_: ohh okay, no crash anymore
21:33imirkin_: doesn't mean that everything in between is hdmi-related
21:33karolherbst: it just doesn't display any results at the end
21:33karolherbst: though it crashe again
21:34nyef: At offset 0xc000 from somewhere...
21:34karolherbst: increasing the TIC/TSC entry size helps then I guess
21:34imirkin_: karolherbst: sure, but it's not the right solution
21:34imirkin_: the right solution is to only make the active textures resident, and treat the rest like a cache that can be evicted as necessary
21:35urmet: imirkin_: I'll try again with boot parameters
21:35karolherbst: okay, we we don't cleanup that table yet?
21:35imirkin_: urmet: sounds like you didn't feed the debug parameter in correctly
21:35imirkin_: karolherbst: only if the sampler view gets deleted
21:35karolherbst: mhh okay
21:35imirkin_: karolherbst: at least... i think.
21:35imirkin_: not 100% sure.
21:36nyef: ... from the base of PDISPLAY, which is given to be 0x610000, which puts it out of range for what the kernel is doing.
21:36karolherbst: how much more memory is getting used by doubling those tables? doesn't seem to be that relevant
21:36imirkin_: nyef: you should assume you're reading it incorrectly :)
21:36imirkin_: adjust your reading until it matches up with what the kernel is doign in hdmigf100.c
21:37karolherbst: imirkin_: until somebody writes a proper solution, we should simply increase those arrays then, because it fixes a crash in a real games
21:38imirkin_: karolherbst: i don't think so...
21:38imirkin_: i suspect it only delays the crash in such a game
21:38karolherbst: okay, that would be bad
21:39nyef: Okay, current best guess: there's a bunch of per-HEAD stuff from 0x616000 - 0x616fff, with the first half being HEAD 0 and the second half being HEAD 1.
21:39urmet: imirkin_: if I read my kernel config right, debug is the default log level and that's all it prints
21:39imirkin_: nyef: applying logic to register layouts like that would be a huge mistake
21:39imirkin_: nyef: different units, which have different behavior per head, per sor, per pior, per whatever
21:39imirkin_: all nicely mashed together into a single mmio space
21:39karolherbst: imirkin_: anyway, I won't have time for any more complex code the next two weeks, so this has to wait then
21:40imirkin_: karolherbst: well, i've downloaded the game now
21:40imirkin_: and queued up a bunch more :)
21:40calim: just make sure they're aligned
21:40karolherbst: imirkin_: nice :)
21:40karolherbst: at least we found the issue now
21:40imirkin_: calim: well, the main thing is that we don't evict unused textures. i think we need to start doing that.
21:40urmet: CONFIG_NOUVEAU_DEBUG=5 and CONFIG_NOUVEAU_DEBUG_DEFAULT=4 (which should be "debug")
21:41calim: I don't remember not evicting
21:41imirkin_: urmet: ah ok
21:41nyef: Unless they're cheaping out on the address decoding, so that it's one address line to a function for certain ranges and functions, thus allowing for multiple registers to be selected at once, it's good for a rough guess.
21:41imirkin_: calim: i could be misremembering. mostly going from memory.
21:42imirkin_: i don't precisely remember what causes an unlock to happen other than texture delete
21:42calim: nvc0_screen_tic_alloc sets tic to 0 when it reallocates and id to a different pipe object
21:42calim: *-1 / invalid
21:43imirkin_: ok. will need to look more closelier then.
21:43imirkin_: are you gonna be back to hacking on nouveau? :)
21:43calim: no :P
21:43calim: maybe in 5 years when Ben is done with all those rewrites
21:44calim: maybe the tic.lock thing is buggy
21:44calim: it's supposed to prevent reallocating slots used by bound objects
21:45imirkin_: i wouldn't be surprised if i broke it. or maybe multithreading is going on and killing it.
21:45imirkin_:has broken tons of stuff over the years... hopefully less than i've added/fixed though
21:45calim: multithreading would kill it, yes, maybe try the d3d9 solution and throw a big lock around all gallium functions
21:45imirkin_: i had a thing which did that
21:46calim: identity pipe with global locking
21:46imirkin_: wasn't as easy to do as it looked without also doing lock(); sleep(); unlock();
21:47urmet: hmmm. I have a full kernel git clone and I'm preeeety sure it worked sometime before. maybe I could bisect it
21:47imirkin_: urmet: that'd be ideal :)
21:48urmet: the biggest problem is that my ESP is really tiny and I have to delete old kernels all the time
21:50calim: a lot of games use more TIC entries than in the table so if something bad happens it must be special
21:50nyef: HDMI audio doesn't seem to be working on gf119.
21:51imirkin_: mmmmm... pretty sure it did at one point
21:52nyef: Could just be my setup, of course.
21:52imirkin_: guess i'm not sure
21:52karolherbst: finally I can work on perf with hitman now :)
21:52nyef: At least it's not the ELD, though. (-:
21:53imirkin_: nyef: the hdagf119 code is used for kepler as well
21:53imirkin_: nyef: some other registers moved around on kepler, so i wouldn't be terribly surprised if it needed to be renamed to hdagk104.c
21:53imirkin_: and then re-figured out for gf119
21:54imirkin_: otoh, i have no clue
21:54nyef: So noted.
21:54imirkin_: hdagf119.c is only used by nvd9, so it limits the visibility of any issues
21:55imirkin_: (nvd7 doesn't have a display unit at all)
21:56nyef: Oh... Wait, things might not be this bad. I just remembered that this isn't an up-to-date kernel that I'm running.
22:12tarragon: has anybody tested virglrenderer/libepoxy with an nvidia card?
22:12tarragon: I want it for gaming.
22:17imirkin_: i have faint recollections of airlied mentioning that nouveau didn't like virglrenderer
22:18airlied: contextx and threads :)
22:32imirkin_: airlied: ah yeah, that'd do it
22:49tarragon: mm.. virglrenderer dev here?
22:49tarragon: airlied: I am trying to run wine games within a VM by using virglrenderer, is there hope?
22:50tarragon: oh wait 'DIDN'T like' :(
23:06MichaelP: GeForce 8400 GS ... video tearing in vlc ... my 20-nouveau.conf https://bpaste.net/show/5842f86b3414
23:08imirkin_: i think the idea is to say true/false rather than "boolean" and to provide the DRI version you want rather than "integer"
23:08imirkin_: either way, the defaults for those should probably be fine
23:09imirkin_: and you shouldn't need this config file at all
23:10MichaelP: imirkin_: need something to stop video tearing
23:10imirkin_: are you using xv?
23:10wrl: so, since I see reference to nouveau in the docs for it everywhere, I'm wondering... does anybody here have experience with mmiotrace and could give guidance for using it for a non-nouveau project? similar idea, but for some undocumented audio hardware
23:10imirkin_: wrl: should Just Work (tm)
23:10tarragon: MichaelP: wow, that's an ancient card!
23:11MichaelP: xv ?
23:11tarragon: I've got one with busted caps.
23:11imirkin_: tarragon: it's a G84 or G98 or GT218... either way, part of what i consider to be the "modern" generation
23:11MichaelP: places still sell old cards
23:11imirkin_: MichaelP: XVideo
23:11wrl: imirkin_: so, I'm interested in doing PCI passthrough from virtualbox/kvm+qemu for a pcie-over-thunderbolt device
23:11wrl: imirkin_: how much fun am I going to have with that, do you know?
23:12wrl: basically, sniffing the protocol from the windows driver
23:12MichaelP: imirkin_: no idea.. still getting everything setup on this pc
23:12imirkin_: wrl: well, mmiotrace ain't magic. the way it works is that after you start it, any driver that does mmio maps gets hooked into, and all instructions that access those maps are trapped and emulated. as part of the emulation, it records what was read/written.
23:12imirkin_: [so, don't use SSE4 intrinsics on io space. heh.]
23:13nyef: Odd... With 4.10.0 (plus local patches), the GF119 isn't detecting the monitor connected to one of the DPorts.
23:13imirkin_: normally this is done in the context of some blob driver that shan't be mentioned
23:13imirkin_: where you start the trace, load the driver, which causes the hooks to happen, then operate it, then look at what all happened
23:13imirkin_: with pci passthrough, that adds an extra layer of "shit". tbh, i'm not 100% sure how pci passthrough works, esp since there are a few such things.
23:13wrl: imirkin_: so, in that vein -- if my goal is to use a thunderbolt device from a virtualbox/kvm VM, should I just suppose that virtualbox itself will perform the mmio mapping?
23:14imirkin_: well, i def have no clue how virtualbox works
23:14wrl: what about kvm?
23:14MichaelP: imirkin_: how do i tell ix using xv or what ever ?
23:14imirkin_: similarly. but at least the code is there :)
23:14imirkin_: MichaelP: sorry, i don't use vlc.
23:15imirkin_: MichaelP: i use mplayer. you can do mplayer -vo xv foo-file.avi
23:15imirkin_: and have that work.
23:15MichaelP: smplayer was doing samething
23:15nyef: Aha! Okay, HDMI-over-DP audio works on the GF119, the output was muted at the mixer level.
23:15imirkin_: nyef: oops :) what about the ELD then?
23:15nyef: The ELD is fine, as I said before.
23:15imirkin_: oh. i thought you said it was missing.
23:15imirkin_: i must have misunderstood.
23:15nyef: Well, the ELD is fine for the display that gets detected as connected.
23:17nyef: I'm going to try to figure out the infoframe stuff for a bit, then power down and swap the monitors coming from the card to see if it's something about a "real" DPport connection that's the problem, or if it's head 0 that's the problem.
23:19tarragon: any confirmation a geforce 8400 can be use as passthrough?
23:26MichaelP: mplayer -vo xv foo-file.avi .. whats it do read the hole video before it gives output ?
23:31nyef: Okay, #x616730 is the audio infoframe control. Which means that if #x6167a4 is an infoframe control then it's the "generic" infoframe.
23:52nyef: Okay, it's the straight DPort connection that doesn't work.