08:19vicky_: I'm seeing an issue mentioned in https://lkml.org/lkml/2019/5/23/873
08:19vicky_: irq 16: nobody cared (try booting with the "irqpoll" option)
08:19vicky_: This is not a Lenovo ThinkPad P50. How do I implement the fix for my hardware? Any pointers will be helpful. Thanks.
09:02karolherbst: vicky_: get the subsystem IDs for your GPU
09:02karolherbst: and adjust the check
09:02vicky_: karolherbst: Thanks.
09:20vicky_: karolherbst: This is the output of lspci http://paste.debian.net/1088293/
09:20vicky_: So subsystem_vendor will be PCI_VENDOR_ID_NVIDIA and what will be subsystem_device? 1cb3/11be ?
10:32karolherbst: pmoreau: you still have one of those old style DSM laptops?
10:32karolherbst: mind checking with my patch on the ML if the runpm stuff still works?
10:33karolherbst: or... at least I think that macbook was one of them
10:33karolherbst: no idea for which systems this path is used
11:16rhyskidd: karolherbst: i have a macbook5,3 (mid-2009) if that would be in scope for testing?
11:17rhyskidd: nv96 and nvac
11:26karolherbst: rhyskidd: yeah... not sure
11:26karolherbst: I really have no idea when that DSM stuff started to be used
11:26karolherbst: but laptops with hybrid grpahics is usually a good bet
13:50mivanov: Hello everyone, I am trying to get an Nvidia K4100M(NVE0,GK104) to work correctly with Nouveau. I've downloaded the source for the kernel driver and the xorg driver and am looking for some pointers.
13:50mivanov: I am having 4 issues:
13:51mivanov: Vsync, PRIME Synchronization, Displayport training with Docking station, Nouveau crashes after suspend and resume on kernels>=4.15
13:52mivanov: For now I'd be content to fix my Vsync and stop getting Tearing. I've tried SwapLimit "2" with GLXVBlank "true
13:52mivanov: Also tried combining with compton or XFCE compositor. So now I am down to trying to fix the nouveau source if the problem is there.
13:53mivanov: Tearing is observed on all kernels so far. However I haven't tested different Xorg versions/Wayland. And also I have only tried 1.0.15 version of the Xorg driver. Will try 1.0.16 today.
13:53mivanov: It would be great if someone could share some insights about the Vsync(ie. Tearing) issues and if they are expected.
13:56mivanov: At the very least I need to know what I have to fix: is it the Xorg driver or the kernel module? And is this tearing local to my GPU or it happens on many other models?(all Keplers or perhaps Fermi too?)
13:59karolherbst: mivanov: you should try out a 5.1 kernel
13:59karolherbst: or even a 5.2 rc
13:59karolherbst: and we have no fix for tearing so far
14:00karolherbst: what's missing is reverse engineering of the line buffer
14:00karolherbst: I think... but it depends on what kind of tearing you got
14:00mivanov: karolherbst, thanks for the suggestion. I did try 5.1 kernels. I get crashes if I suspend and resume: evo drm timeout or something
14:00karolherbst: ohh heh
14:00mivanov: I have tearing when there is a lot of horizontal movement.
14:00karolherbst: mind bisecting which commit is causing it?
14:01mivanov: About the tearing or the crash?
14:01karolherbst: but I think somebody was already looking into that
14:01karolherbst: the crash
14:01karolherbst: imirkin: ? crash on resume, evo drm timeout stuff? I think you hit that as well, no?
14:01mivanov: The crash happens on all kernels after 4.14: https://bugzilla.redhat.com/show_bug.cgi?id=1618906
14:01mivanov: and this
14:02mivanov: Someone in those issues has already pointed out the suspected commit that's causing it.
14:02mivanov: I've tried various 4.19, 5.0 and 5.1 kernels and so far they are all affected and nouveau crashes on resume
14:03karolherbst: mivanov: mind verifying that using the commit before the suspected one doesn't show the issue and with the suspected one it does?
14:03karolherbst: just to verify it's the same issue
14:04mivanov: I can try doing that later, but it would require me setting up a build environment to build the nouveau kernel module and cherry-picking that specific commit.
14:05mivanov: For now I only have set-up the environment to build the Xorg driver since I am trying to fix the Vsync issues first.
14:05karolherbst: ohh, I see
14:05karolherbst: although building a kernel is more or less trivial
14:05karolherbst: only need gcc
14:05karolherbst: (and other trivial stuff)
14:05karolherbst: the vsync stuff is a bit messier to fix
14:05mivanov: I guess but I need to stick to some specific configs since I am using a Xen hypervisor :)
14:05mivanov: The vsync stuff is all in userland or so it seems?
14:06mivanov: But I read a lot of code implementing Vsync in the xorg driver. By firmware do you mean vbios?
14:06mivanov: Or the kernel module as well?
14:06karolherbst: no, actual firmware ran on some GPU coprocessors
14:07mivanov: So to get Vsync working correctly I have to dump the VBIOS?
14:07mivanov: And then modify the kernel module or the Xorg driver?
14:07karolherbst: this has to be implemented for kepler+
14:07karolherbst: or well kepler + GF119
14:07karolherbst: the implementation for older gpus is above
14:08karolherbst: I have no idea who looked into it and what's the status
14:08mivanov: So everything else is in place? Just need the low-level instructions?
14:08karolherbst: I think so
14:09karolherbst: it depends on what's actually missing
14:09mivanov: Not that it sounds easy though
14:09karolherbst: maybe we have to set something up on the GPU as well which might require driver chagnes
14:09mivanov: Hm, I wonder about the Vsync code in the Xorg driver
14:09karolherbst: well there is always a kernel and a userspace part
14:09karolherbst: somehow the driver has to tell X when a vblank happened
14:10karolherbst: in order to implement a proper vsyncing
14:10mivanov: The same code is used for Fermi and above, no specific code for Kepler
14:11karolherbst: should be, yes
14:11mivanov: Hm, is there some Docs where I can read how Vsync is implemented in the Linux Graphics Stack? I am a developer but am new to Video drivers and such.
14:11karolherbst: that's not relevant, what's important are hw docs about the GPU
14:12karolherbst: and we don't have those
14:12imirkin_: karolherbst: the issue i hit would have been quite different
14:12karolherbst: imirkin_: yeah.. makes sense
14:12imirkin_: mivanov: what are you attempting to fix exactly? ("vsync issues" is pretty generic, and frequently unrelated to vsync)
14:13mivanov: When I play a video or move a window horizontally there is tearing.
14:13imirkin_: are you playing the video with vdpau?
14:13mivanov: No, just software decode.
14:13imirkin_: vdpau on kepler is known to have funny vsync issues, i never felt like investigating
14:13karolherbst: imirkin_: well, we don't support waiting for vblanks on kepler :p
14:13imirkin_: tearing is also normal on xorg
14:14mivanov: And the tearing happens when moving windows too.
14:14karolherbst:doesn't have tearing
14:14imirkin_: however if you run with a redirecting compositor, you should not see tearing
14:14mivanov: I've tried compton and the XFCE compositor. Both don'
14:14imirkin_: so ... question is, are you running with a redirecting compositor?
14:14mivanov: Hm, compton and XFCE compositor do not help
14:14mivanov: Also I
14:14mivanov: ve tried with Intel graphics and there is no tearing with or without compositors
14:15karolherbst: well, software is able to mitigate a lot, but all that isn't a proper fix anyway
14:15imirkin_: which xorg ddx are you using?
14:16imirkin_: modeset or nouveau?
14:16mivanov: xf86-video-nouveau 1.0.15
14:16karolherbst: imirkin_: I also saw tearing on my gm204 with nouveau and kwin+compositing and everything
14:16mivanov: what do you mean by ddx?
14:16imirkin_: mivanov: sure it's not modeset?
14:16imirkin_: (please double-check xorg log... does it say "modeset(0)" or "NOUVEAU(0)"?
14:16mivanov: Can't check right now, but as far as I remember it'
14:17mivanov: s NOUVEAU(0)
14:17imirkin_: karolherbst: was this with reverse prime? if so, reverse prime = tearing
14:17mivanov: I've have tearing regardless of Prime, disabling the intel graphics and running on nouveau only doesn't change a thing
14:17karolherbst: imirkin_: no, just the gm204
14:17imirkin_: well shit, then.
14:18karolherbst: it's an issue we have for since forever
14:18karolherbst: software is usually good enough to mitigate it as much as it's not really a big issue
14:18karolherbst: but sometimes...
14:18mivanov: I've read that nouveau only supports modesetting, so what do you mean by ddx? and using xf86-video-nouveau 1.0.15 vs modeset
14:18imirkin_: mivanov: ddx is the "device-dependent X" driver
14:19imirkin_: there's a "modeset" driver which uses kms interfaces + glamor (aka GL) to implement acceleration
14:19imirkin_: there's a "nouveau" driver which is a bit more targeted
14:19mivanov: so which one should I use
14:19mivanov: I guess the nouveau driver?
14:19imirkin_: that's certainly the one i'd recommend
14:19imirkin_: however some distros have patches to force modeset to get used for newer devices
14:19karolherbst:has to properly read the code to see how all that vblanking and stuff actually works
14:20karolherbst: mivanov: ohh, by any chance, are you using two displays?
14:20mivanov: I am actually
14:20imirkin_: ah, that makes a big difference
14:20imirkin_: since the two aren't frame-locked
14:20karolherbst: right... I think that's the stuff which is really not working all that well
14:20mivanov: Okay, I will try today using only a single monitor
14:20imirkin_: i think there's one which will be the "main" one
14:20karolherbst: so one tears and the other should be fine?
14:20imirkin_: and that one won't tear, in theory
14:21imirkin_: (which one is not extremely deterministic)
14:21mivanov: I will use xrandr to disable laptop screen and leave only one monitor on then.
14:21mivanov: But I think I've already tried that
14:21mivanov: Can't remember right now
14:21karolherbst: mivanov: ohh right, it's a laptop with intel+nvidia, right?
14:21mivanov: But I've disabled the intel
14:22karolherbst: can you put it into dedicated only mode?
14:22mivanov: Also I've tried using Nvidia as the Primary GPU
14:22mivanov: So Intel has to use Prime
14:22imirkin_: it's funny - i've never really paid attention to all these issues - tearing just doesn't bother me that much
14:22mivanov: It started bothering me when I watched some movies :)
14:22imirkin_: except with glamor, where the tearing is along the diagonal
14:22karolherbst: imirkin_: it's actually not _that_ bad with only one display
14:22mivanov: Otherwise when coding I don't really care
14:23karolherbst: I think I never really notices it, just sometimes
14:23karolherbst:should probably look into it
14:23imirkin_: nah, i definitely notice it
14:23imirkin_: esp with movies yea
14:23mivanov: Also I've downloaded a Tearing test video and now everyday I occasionally play it. Then I start noticing tearing everywhere. Get mad and start reading the sources of the kernel module and the Xorg driver :D
14:24imirkin_: yeah unfortunately it's not just a --work-correctly option somewhere we're missing =/
14:24imirkin_: these things are wildly subtle
14:24imirkin_: imagine 2 monitors with different refresh rates
14:24mivanov: I can't attach the monitor to the Intel graphics because the Intel driver has issues with high resolution. So I really want to fix the tearing.
14:24mivanov: Actually I use the same refresh rate of 60hz everywhere.
14:24karolherbst: imirkin_: ohh, mind writing up a GSoC/EVoC style summary of the frame lock stuff?
14:24mivanov: Because I thought that might provoke tearing.
14:24karolherbst: we might jsut want to put it on the project list
14:24imirkin_: mivanov: sure, but imagine it's different
14:25imirkin_: or imagine it's 60hz, but 180 degrees out of phase
14:25mivanov: You mean like rotating the screen
14:25imirkin_: karolherbst: frame-lock is a hardware feature available
14:25imirkin_: mivanov: no, just the vblank periods being at different times
14:25mivanov: I see
14:25karolherbst: imirkin_: so it's mostly reverse engeineering, right?
14:25mivanov: Out of sync
14:25imirkin_: karolherbst: ... available on quadro boards, and i think only older ones
14:26karolherbst: uff :/
14:26imirkin_: mivanov: "out of phase" :)
14:26karolherbst: imirkin_: okay, so what do we do with newer gpus then? anyway, maybe I should just write it and phrase it more on a higher level "make dual display not tear" or something
14:26karolherbst: or more generic
14:26karolherbst: "nouveau tearing fixes"
14:26imirkin_: karolherbst: honestly, i have no idea.
14:27imirkin_: i think you create a dedicated image per head
14:27karolherbst: k... we get to that if somebody is interested working on it :p
14:27imirkin_: and vsync each one separately
14:27imirkin_: this is the "TearFree" option in intel and amdgpu ddx's
14:27mivanov: But actually I think the Tearing will happen even with one monitor only.
14:28karolherbst: imirkin_: right.. that thing which is enabled by default
14:28imirkin_: the trick is to avoid doing 100 blits to make that happen
14:28imirkin_: karolherbst: TearFree is not on by default
14:28karolherbst: imirkin_: it's for me
14:28orbea: i used compton to not tear in nouveau (and with amd + modesetting)
14:28imirkin_: karolherbst: probably a fedora patch then
14:28mivanov: tried compton, but did not help really
14:28karolherbst: imirkin_: probably
14:28karolherbst: might explain some funky blanks
14:29karolherbst: anyway... we should put such projects on our GSoC list
14:29karolherbst: we don't have any better list of things to do...
14:29karolherbst: or well, project like things
14:29imirkin_: i can only imagine the poor GSoC student crying in a corner...
14:29karolherbst: sure... but it doesn't have to be for GSoC only
14:30karolherbst: and even implementing it 25% would be good enough
14:30imirkin_: you'd rather be the one crying in a corner? :p
14:30orbea: mivanov: compton needs specific settings to work with nouveau ime https://wiki.archlinux.org/index.php/Nouveau#Vertical_Sync
14:30orbea: but maybe I was just lucky :)
14:30karolherbst: imirkin_: right.. but I also want to use that list for internships and stuff
14:30mivanov: I've tried that but with the new compton forks
14:30karolherbst: anyway, I want to have more project ideas there
14:30imirkin_: i have countless ideas
14:30imirkin_: no one to implement them
14:30mivanov: Since compton has now new commit since a long time ago. I toke the fork for yshui and compiled it
14:30karolherbst: write them down :)
14:31imirkin_: and no time to mentor someone should they appear
14:31karolherbst: I can clean anything up you wrote down and add it to the wiki :p
14:31mivanov: orbea: vsync drm was deprecated in the new compton, only gl, but I enabled it, recompiled. does not help
14:31imirkin_: most of the ideas are already in the wiki
14:31imirkin_: i wrote up a bunch like 3-4 years ago
14:31karolherbst: so, some are still missing :p
14:31karolherbst: yeah.. I also added some a few years ago
14:31imirkin_: none have had material interest in them
14:32imirkin_: it's all backwards
14:32imirkin_: the projects that sound interesting are all WAAAY too hard
14:32karolherbst: :/ sadly
14:32karolherbst: anyway, tearing is a big thing missing there
14:32imirkin_: and we've done the easier projects
14:32karolherbst: imirkin_: anyway, my idea is to get the intern interested in one of those
14:32imirkin_: there's an immense learning curve before you can do *anything*
14:32karolherbst: and we have a year time
14:32karolherbst: so... we might be able to get somewhere
14:33imirkin_: the GSoC projects should be things that "we" (i.e. experienced project members) should be able to achieve in a fraction of the GSoC timeframe
14:33mivanov: karolherbst: anyway, what about that https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/memx.fuc?h=v5.2-rc5#n209
14:33mivanov: is the problem actually here
14:33karolherbst: imirkin_: I know :/
14:33imirkin_: mivanov: why are you focusing on pmu stuff? that's for changing clock rates, and trying to do it during vblank periods
14:34imirkin_: (like memory clock rates)
14:34karolherbst: mivanov: no idea to be honest. Might be, might not be. It might only be related to reclocking, which we also have to fix for kepler
14:34karolherbst: well, screens doing weirdo blanks when reclocking
14:34imirkin_: sure, but that's not the issue being complained about
14:34karolherbst: but on kepler we actually have a linebuffer we have to fill
14:34karolherbst: my mistake
14:35mivanov: Does the GPU clock matter? Since I am not running any games, etc. it's always at the min. Not sure if it can scale up
14:35orbea: mivanov: new compton? I see no reference of it being deprecatd here https://github.com/chjj/compton
14:35karolherbst: mivanov: mhh, in theory with higher clocks it should tear less... maybe
14:35karolherbst: depends on the kind of tearing
14:36karolherbst: or more
14:36imirkin_: but definitely not the same :p
14:36karolherbst: maybe that as well? I am just guessing
14:36mivanov: orbea: no commits in years, so I thought so. Plus Archlinux referenced this: https://github.com/yshui/compton
14:36karolherbst: but I can imagine it makes a difference
14:37mivanov: So does Nouveau support changing the GPU Frequency?
14:37mivanov: For Kepler
14:37orbea: ah, didn't realize someone forked it
14:37orbea: the old one still just works for me :shrug:
14:37mivanov: It says it does: Support for manual performance level selection (also known as "reclocking") on GM10x Maxwell, Kepler and Tesla G94-GT218 GPUs
14:37karolherbst: imirkin_: anyway, regarding the GSoC project list, I would rather add very high level features and then we can always find smaller pieces to work towards the higher goal... might be easier than to come up with small technically sounding projects nobody understands and won't be interested in :/
14:37karolherbst: mivanov: yes
14:37karolherbst: mivanov: but you have to do it manually
14:38karolherbst: mivanov: /sys/kernel/debug/dri/0/pstate is the file to do that
14:38karolherbst: 1 if you put your laptop in hybrid mode
14:38karolherbst: orbea: isn't the xfwm compositing enough?
14:38mivanov: So that's another interesting thing to try I guess. My GPU is at 15W all the time. Wondering how much it will go up
14:38karolherbst: mivanov: by a lot
14:38mivanov: orbea: I guess I have to try the old one.
14:38orbea: karolherbst: i often use just compton with no window manager via xinit /path/to/launcher.sh -- :1
14:39karolherbst: mivanov: it's a 100W GPU afterall
14:39karolherbst: and I guess it will idle at around 40 W or something
14:39orbea: mivanov: might just be I was lucky...
14:39karolherbst: mivanov: we have nouveau.config=NvPmEnableGating=1 to reduce power consumption though
14:39mivanov: karolherbst: that's not very good. it's summer now, the GPU is at 50-55 C idle at 15W
14:39karolherbst: boot with nouveau.config=NvPmEnableGating=1
14:39karolherbst: it might cut of 2 or 3 W
14:40mivanov: will try some experiments with it but does not sound too good to fry the whole thing :)
14:40karolherbst: you won't be able to fry it
14:40karolherbst: there are multiple layers of protection
14:41karolherbst: and as long as you don't reach 100C everything is fine
14:41karolherbst: around 105C the GPU just turns itself of
14:41mivanov: I guess
14:41karolherbst: but that gating thing is something you really want to try out
14:41karolherbst: enable it and run with it a while, if there are no issues, good
14:41karolherbst: we don't really enable it by default for now
14:42karolherbst: as it's untested...
14:42karolherbst: and if it's not enabled by default... nobody tests it
14:42karolherbst: it's a big problem :/
14:42karolherbst: but it can save quite a lot of power
14:43mivanov: So anyway what options do I have: trying the older compton, higher clocks with gating, trying to add instructions to that memx.fuc file, making sure that I am using nouveau as ddx and not modeset
14:43karolherbst: I guess in the end you can only wait or try implementing it yourself
14:43karolherbst: I have no idea what's actually required to do that
14:43karolherbst: would have to read some code
14:43mivanov: imirkin_: are we sure the Vsync issue is not related to the vsync code in the nouveau ddx
14:43imirkin_: we are not.
14:44mivanov: I am looking at this file: src/nvc0_xv.c
14:44mivanov: But I will have to invest some more time these days to read the whole thing.
14:44imirkin_: that's related to Xv(ideo)
14:45imirkin_: which iirc is not explicitly vsync'd
14:45imirkin_: only GL clients would be vsync'd
14:45imirkin_: i forget, tbh
14:46mivanov: Why only GL clients? What about random windows?
14:46imirkin_: that's not how X works.
14:46imirkin_: this isn't wayland.
14:46mivanov: Then how does the TearFree option on Intel works
14:46mivanov: it fixes all tearing everywhere
14:46imirkin_: that's right
14:47imirkin_: it does an extra copy from the X "root" window
14:47imirkin_: into per-head buffers
14:47imirkin_: which are managed separately
14:47mivanov: How hard is it to do that for Nouveau
14:47imirkin_: shouldn't be crazy, i think
14:47imirkin_: esp given that we wouldn't be the first ones to do it
14:47imirkin_: (thus having to figure out how to do it...)
14:47imirkin_: since you want to disable that for a full-screen composited client
14:48mivanov: So you're saying that the current GLXVBlank is only related to OpenGL based things
14:48imirkin_: as the name implies, yes.
14:48imirkin_: GLX clients
14:48mivanov: What about the SwapLimit
14:48imirkin_: it's related to GLX, I believe
14:49mivanov: So if this TearFree equivalent is to be implemented it has to be only in the Xorg Nouveau driver or?
14:51mivanov: So to clear up something, is Vsync something only related to Xorg and the Xorg driver? Or do kernel modules also have to implement it?
14:51imirkin_: kernel module implements notifying userspace of vblank events
14:52imirkin_: there's also another mechanism of implementing vsync which is actually used by the xorg ddx
14:52imirkin_: it sends down a software event, iirc
14:52imirkin_: which is processed by the kernel module
14:52imirkin_: (the gpu throws an interrupt when it hits that method in its fifo processing)
14:53imirkin_: did i mention it was complicated? :)
14:55mivanov: I need to read more, a lot more :)
14:57mivanov: I do not even know what a vblank event is. And I thought it was much simpler. Just a framebuffer that I want to flush :)
14:58mivanov: Anyway guys, I have to go. Thanks for your help. Will read up on vblank events and look at the impelemntation of the TearFree in the Intel graphics.
17:06karolherbst: imirkin_: https://trello.com/c/qSY3qw7o/213-nv50-bards-tale-misrendering is this still an issue? I actually own the game
17:07imirkin_: it's not
17:07imirkin_: or rather
17:07imirkin_: it is, but it's the game's fault
17:07imirkin_: it does something slightly dodgy
17:07imirkin_: and nouveau does something slightly dodgy
17:07imirkin_: and the two dodiginesses collid
17:08imirkin_: basically the problem is ... "what happens when you use an out-of-bounds index into a vbo"
17:08imirkin_: on nvc0+, we return the data for index 0 (well, the hw does)
17:08imirkin_: on nv50, we return 0's for all the vertex attribs
17:08imirkin_: now, some of those attribs are used to index into a constbuf, which contains totally bogus values at index 0
17:09imirkin_: (relative to the thing they're trying to use it for)
17:09imirkin_: which in turn causes that stupid triangle
17:09imirkin_: i'm fairly sure this is just how the hw works
17:09imirkin_: we could have a quirk which preloads the "runout" buffer with non-zero values, but rather ones based on the contents of the vbo
17:10karolherbst: do you know what nvidia does?
17:10imirkin_: that constbuf is all kinds of fail too
17:10karolherbst: mhhh, and I am sure the opengl specification just says this is undefined?
17:10karolherbst: and return 0 for robustness?
17:10imirkin_: pretty sure, yeah
17:11imirkin_: either 0 or any element in the vbo
17:11imirkin_: (that's *with* robustness... without, you can set the card on fire)
17:11karolherbst: well, but the game doesn't require, right? So we are in the set the card on fire mode...
17:11imirkin_: this GL port was done well before robustness though
17:12imirkin_: they do something annoying too
17:12imirkin_: they have this one mega-constbuf
17:12imirkin_: which is just like vec4 array or whatever
17:12imirkin_: but it's secretly a bunch of different arrays, containing very different data
17:12imirkin_: and they index into it based on ... stuff
17:13imirkin_: and coz of the unexpected 0
17:13imirkin_: it ends up pulling a value out of the "wrong" part of the constbuf
17:14karolherbst: what I am wondering is, that they had to port this game on a driver which has more or less deterministic behaviour here so they didn't notice (or didn't care)
17:14imirkin_: iirc it's a GL2 game
17:14imirkin_: perhaps there's a secret setting on nv50
17:14imirkin_: to do the other thing - i.e. pull data from index 0
17:14karolherbst: ohh, interesting
17:15imirkin_: but there's no way the shader can detect the condition
17:15karolherbst: so if we return 0 on invalid read (nvc0+) it's all fine
17:15imirkin_: since it's a perfectly valid index into the constbuf
17:15imirkin_: it just contains unexpected data at that index
17:15karolherbst: ohh wait, the other way around
17:15imirkin_: on nvc0+, we return data from index 0
17:15imirkin_: and that has valid values for the various attribs
17:15imirkin_: so it probably redraws some triangle 2x or whatever, no big deal
17:16imirkin_: and/or it otherwise works out
17:16imirkin_: but with the unexpected attrib value - it's pile-o-fail
17:16imirkin_: actually i have an idea...........
17:16imirkin_: we only fill a vec4's worth of 0's
17:17imirkin_: perhaps we have to fill 16*vec4 worth of 0's
17:17imirkin_: otoh, dunno
17:17imirkin_: i hate buggy games.
17:17karolherbst: do you know what happens on AMD/Intel?
17:17imirkin_: index 0
17:17imirkin_: nv50 is special :)
17:18imirkin_: has that stupid runout thing
17:18karolherbst: nv50 is also this gen which is super annoying to re, because of the binary driver :/
17:18imirkin_: binary driver on all gens...
17:18karolherbst: well, older kernel version and all that kind of fun
17:18imirkin_: oh wtvr
17:18karolherbst: legacy driver
17:18imirkin_: nv4 is a lot more annoying :p
17:18karolherbst: well.. more annoying than to just use your recent kernel
17:19karolherbst: :D true
17:19imirkin_: i've never even tried tracing a nv4x
17:19imirkin_: much less a nv5
20:56karolherbst: *sigh*, apperantly my imms to cb opt is broken
20:59karolherbst: yeah.. I think uploading the immediates is more or less broken...
20:59karolherbst: the shader seems to be correct
21:05imirkin_: coudl be shader cache playing tricks?
21:05imirkin_: or we don't actually cache yet
21:26karolherbst: no.. I am sure the immediates won't get uploaded
21:32karolherbst: heh.. so not uploading the immediates looks the same as uploading them... so something is funky
21:32imirkin_: should just never upload them - faster that way!
21:33karolherbst: kernel messed up
21:34karolherbst: so apparently if I want to upload more data into a cb than there actually is, we get a "[TTM] Buffer eviction failed"
21:34karolherbst: and a lot of fail