02:41Benau: so imirkin do you need a bug report about stk / or you can remember it
04:10imirkin: Benau: it certainly wouldn't hurt :)
04:11imirkin: let me track down the shader and compile it for nv50 and see if there's anything horribly wrong
04:12Benau: actually i can be here so you can tell me if there is anything want to try on my system
04:20imirkin: Benau: does NV50_PROG_OPTIMIZE=0 glretrace foo.trace fix it?
04:20Benau: need boot
04:20Benau: 3 min
04:28Benau: no, it doesn't work
04:31imirkin: Benau: ok, priority-wise, this is behind making bindless work on maxwell. mostly because i have a maxwell plugged in, and not a tesla.
04:34Benau: do u think piglit test worth a try in my system?
04:34Benau: (for tbo)
04:42imirkin: wouldn't hurt
04:43imirkin: Benau: bin/arb_texture_buffer_object-subdata-sync -auto
04:44imirkin: and bin/arb_texture_buffer_object-data-sync
04:44imirkin: there's a bufferstorage one too
04:45Benau: fyi the apitrace recorded has buffer storage disabled
04:45Benau: because it doesn't support persistant mapping + record trace
04:46imirkin: persistent + trace is supported
04:46imirkin: coherent + trace is not supported
04:46Benau: ar yes i used coherent
05:13Benau: ....building piglit
05:15imirkin: sorry for all the trouble =/
05:15Benau: don't worry
05:25imirkin: SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video"
05:25imirkin: SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0666"
05:25imirkin: so that causes the st_mode of card0 != renderD128
05:25Benau: observed 0 0 0
05:25imirkin: Benau: which one?
05:26Benau: bin/arb_texture_buffer_object-subdata-sync bin/arb_texture_buffer_object-data-sync
05:26imirkin: ok. so i'm 99% sure this used to work
05:26Benau: actually all 3 tests you pointed to me failed
05:27Benau: (and did you mean to pass -auto for all of them)
05:27Benau: so auto close the window
05:27imirkin: yes, -auto
05:27imirkin: and/or -fbo -auto
05:27imirkin: result should be the same tho
05:27imirkin: anyways ... ok. can you try with older checkouts of mesa?
05:27imirkin: i'm thinking that the _LZ support changes messed it up...
05:27imirkin: can you quickly try... hold on
05:28imirkin: comment out this line: case PIPE_CAP_TGSI_TEX_TXF_LZ:
05:29imirkin: brb, gotta restart X
05:38Benau: comment it out doesn't work except console spamming with unknown PIPE_CAP 143
05:39imirkin: the spamming's expected
05:39imirkin: ok, so it's something more subtle
05:39imirkin: let's look at the log...
05:40imirkin: nothing obvious =/
05:40imirkin: try older mesa versions, see if things start to magically work :(
06:02imirkin: ok. i've un-fucked imageSize() now in my bindless series.
06:05Benau: btw last time i tried bindless texture in my windows amd card it's actually slower
06:08imirkin: it'll def be slower than just binding images
06:09imirkin: you can (a) have a lot more textures easily
06:09imirkin: and (b) you don't have to keep binding/unbinding/rebinding all the time
06:09imirkin: so ... depends on the use-cas
06:10Benau: btw i'm not sure if you use radeonsi shader compiles (share code?) but seems that last time i check if you use for example vertex attribute uvec4 handles;
06:10Benau: i can only get handles.xy for a correct one
06:11Benau: handles.zw is not the texture handles i want
06:11imirkin: hmmm... that should be roughly equivalent
06:11Benau: where uvec4 is 16bytes
06:11imirkin: i find that surprising. hakzsam ---^
06:11Benau: anyway it's few months ago mesa
06:12Benau: not sure if you have fixed it
06:12Benau: (and stk don't use bindless texture anymore)
06:12imirkin: there was a bug in handling uniforms in various rather odd cases ... dunno if it'd get hit or not
06:12imirkin: commit 0332c7484b712e56ce1a6648c5fa04c90e286c37
06:13imirkin: but that shouldn't really affect your scenario i think
06:13Benau: also few months ago mesa if i use flat out uvec4 to fragment shader, and than sampler2D in fragment shader for texture handles it will crash the shader compiler
06:14Benau: again not sure if you guys fix it
06:14Benau: (radeonsi only)
06:19imirkin: that's probably radeonsi-specific
06:20imirkin: you should always feel free to report errors
06:20imirkin: esp the other drivers tend to be much better staffed
06:26imirkin: karolherbst: looks like my bindless maxwell patches work... will test DOW3 later, but basic tests pass now.
08:23Benau: imirkin fyi f84bb6a9d91521de6da4c3d1ddd8de456761efaa is one of the commit working for me
08:24Benau: afb8f2d4a346041adf54d45729963a55a625ac1f doesn't work
08:24Benau: 554 commits between...
08:28karolherbst: Benau: 554 is fast enough
08:28karolherbst: on the kernel side you can get 10k
08:28karolherbst: not that it matters much, because you do only lg2(commits) steps anyway
08:30Benau: yeah i try to narrow down more
08:32Benau: 556f70b is still working
08:32Benau: now i go to work
09:36hakzsam: imirkin: yeah it is, but vertex attributes with bindless are fairly untested
09:36hakzsam: could be a bug
13:34Montecristo94: Hi, someone would be so kind to tell me what's the current state of support for 10xx GPUs, i particular GTK 1060? Thanks
13:39imirkin: Benau: w00t! this might not be my fault!
13:40Benau: mesa bug?
13:40imirkin: the bug you're hitting
13:40imirkin: i don't see any of my commits in the range you posted
13:41imirkin: looks like mareko pushed a ton of TBO changes
13:41imirkin: pretty sure it'll be e.g. this one: 8aba778fa2cd98a0b5a7429d3c5057778a0c808c
13:42Benau: ok wgen i go home i can check thid
13:43imirkin: you're using 'git bisect' though, right?
13:43imirkin: if so, just let it do its job
13:44imirkin: Montecristo94: what are you specifically interested in?
14:00Montecristo94: imirkin: I'd be satisfied already if udevd succefully loaded the kms module at boot and set proper resolution for virtial console,while xf86-video-nouveu would handle a Xorg instance without causing a kernel panic ;)
14:00imirkin: Montecristo94: you should be satisfied then.
14:00imirkin: i'm not particularly aware of any such serious GP106 issues
14:01Montecristo94: fantastic, thanks!
14:01imirkin: the experience won't be perfect though
14:01imirkin: and i suspect you won't be particularly satisfied if you use any of the new-fangled stuff
14:02Montecristo94: 1 year ago I had tried on both Linux and NetBSD, and there was no way to make nouveo reach that GPU
14:02imirkin: sounds right
14:03imirkin: note that for (even the most basic of) acceleration, you need to install linux-firmware which contains nvidia-signed blobs to upload into the GPU
14:03Montecristo94: and Xorg loaded vesa, which caused a core dump with it, can't figure why
14:03imirkin: odd. vesa should work. but perhaps once nouveau tried to load, it messed things up. vesa is a pretty fragile thing.
14:03Montecristo94: ok didn't know about this, thanks :)
14:04Montecristo94: yup, framebuffer driver worked though
14:22imirkin: can't have both fbdev vesa and Xorg vesa
14:22imirkin: er, maybe you can. dunno.
16:22Benau: imirkin confirmed 8aba778fa2cd98a0b5a7429d3c5057778a0c808c bad commit
16:22Benau: 222a910a9bff5f4138794e0ef69775a1acdad35a good
16:34imirkin_: Benau: ok cool
16:34imirkin_: so ... this all sounds familiar
16:34imirkin_: he tried it before
16:34imirkin_: and i stopped it
16:34imirkin_: he's kinda right ... a sampler shouldn't be required
16:34imirkin_: iirc i had that problem on fermi, but i worked around it somehow
16:34imirkin_: need to check into how
16:34imirkin_: will investigate tonight (i.e. in ... 8h or so)
16:37imirkin_: it's definitely weird, since there clearly isn't a sampler involved
16:37imirkin_: i think it's something more subtle going on
16:37imirkin_: but binding a sampler helps, so ... move on with life i guess :)
16:37imirkin_: Benau: thanks a lot for bisecting btw!
18:38Yardanico: Hello everyone, can someone add GTX 750 v2 to https://nouveau.freedesktop.org/wiki/CodeNames/ to NV110 family? I have this GPU. For more info - https://www.techpowerup.com/gpudb/2778/geforce-gtx-750-v2
18:38Yardanico: (btw, I regret that I have GM206 and not GM107 version, because I could've used nouveau with reclocking)
18:43Yardanico: btw, as I understand it's not possible to have reclocking support on maxwell2 with nouveau and proprietary firmware (if user will download that firmware himself) ?
18:49Yardanico: because I saw this - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839139 and was hoping that this would add reclocking support for GM206
18:49Yardanico: ah probably nouveau just doesn't know my GPU?
19:20imirkin_: Yardanico: reclocking is actually kinda-sorta possible with GM20x, but we can't control the fan
19:20imirkin_: which is unfortunate
19:21imirkin_: Yardanico: not sure what you mean by "nouveau just doesn't know my GPU"
19:21Yardanico: well yeah this was stupid, I know that nouveau doesn't detect exact GPU model, it detects chipset, vram and so on
19:21Yardanico: imirkin_: NvFanless=1 option?
19:23imirkin_: yeah, no reason to worry about exact model number... it's simultaneously too much and not enough info
19:23imirkin_: still a ton of variation within a single pci-id
19:23imirkin_: so really we just use the chip id to drive everything
19:24imirkin_: i don't think karol's fanless reclocking is upstream yet, and it'd be ill-advised if your board has a fan
19:24imirkin_: (which is controlled by the gpu)
19:24Yardanico: oh, and nvidia doesn't want to release new signed firmware blobs for nouveau? :(
19:25imirkin_: well, they never released blobs that support reclocking
19:25imirkin_: but turns out that we can do almost everything in the "insecure" mode
19:25imirkin_: except adjust fan speed :)
19:26imirkin_: want to disconnect vram from the bus? sure, go ahead. want to toggle fan speed? gotta have signed firmware.
19:28Yardanico: so it seems everyone who has fan on their GPU and has GM2xx+ is stuck at binary drivers :( "smart" move from nvidia to allow fan speed change only on signed firmware.
19:28Yardanico: I think my next gpu is gonna be from AMD for sure
19:28imirkin_: or stuck with low perf
19:29imirkin_: and yeah, i def recommend avoiding nvidia for your next gpu purchase
19:37Yardanico: but really, what is the reason for nvidia to allow only signed firmwares? why doesn't AMD do that? are nvidia afraid of some people flashing "fake" firmwares on their GPUs?
19:37Montecristo94: to the one who helped me today (can't recall name): nouveau work amazingly now with GTX 1060 6Gb
19:37Montecristo94: using a custom 4.15 Zen-Kernel at the moment,on void linux
19:37Montecristo94: thanks again
19:38loonycyborg: Aren't there higher grade nvidia cards that are differentiated from "gaming" variants only by firmware?
19:38loonycyborg: they probably want to prevent people from bypassing their silly market segmentation schemes
19:43imirkin_: Yardanico: "security"
19:43imirkin_: i think in practice, it's to help avoid the fake parts industry in china. not sure.
19:43imirkin_: Montecristo94: glad it worked out
19:50loonycyborg: imirkin_: how exactly that would foil a fake part? If they can make a fake card in the first place they for sure can make it load any firmware they want.
19:51imirkin_: different types of fakes i suppose
19:51airlied:assumes the firmware is only signed, not encrypted
19:51imirkin_: apparently there were a bunch of problems with e.g. a GT 240 being shipped with a vbios altered to make it look like a GTX 650 or something
19:52imirkin_: airlied: yes, only signed, not encrypted.
19:53loonycyborg: and vbios is covered by the signature?
19:54imirkin_: i think yeah
19:54imirkin_: i'm a bit weak on what protects what
19:54imirkin_: and i think they definitely went overboard relative to what they needed to do to protect against that one thing
19:55imirkin_: which is why they fell back on "security!"
19:55imirkin_: one could imagine a virus sitting in the rtos pretty easily