02:39 hansg: Hi All, after a bit of a detour cleaning up acpi/video_detect.c backlight handling I'm back to working on nouveau, and specifically back to:
02:39 hansg: https://bugs.freedesktop.org/show_bug.cgi?id=90435
02:39 hansg: Which is about nv46 sync-to-vblank not working
02:40 hansg: I've just build the standalone nouveau version from http://cgit.freedesktop.org/~darktama/nouveau and something weird is going on, that version works ...
02:41 hansg: Going back to the linux-3.20 tag in that repo things still work, where as the module from the Fedora kernels (upto 4.1-rc7) does not work ...
02:42 hansg: I'm going to do a full kernel build using Linus' latest master now, and see what that does.
07:29 imirkin_: hansg: note that ben's branch has *only* nouveau, not the rest of drm. sometimes changes don't break the ABI but are still logical changes.
07:29 imirkin_: hansg: also there are patches from... someone, on dri-devel, re nouveau's vblank logic iirc
07:32 imirkin_: hansg: ah, from danvet. "drm/nouveau: Use drm_vblank_on/off consistently"
07:33 imirkin_: and looks like it's re suspend/resume, so... probably not what you're seeing.
11:08 briocalter: using mesa 10.5.4 on fedora 22, trying to run gzdoom 1.8.10, getting only garbled graphics
11:09 imirkin_: what gpu?
11:09 briocalter: any hints? also, all games on steam hangs tho PC
11:09 briocalter: VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 660 Ti] (rev a1)
11:09 imirkin_: weird
11:10 briocalter: very, using default X configs
11:10 imirkin_: pastebin dmesg + xorg log + glxinfo -- just in case something's awry
11:11 briocalter: lots of INVALID_BITFIELD on dmesg
11:12 imirkin_: yeah just pastebin all the logs :)
11:13 briocalter: sure, sec
11:15 briocalter: http://pastebin.com/index.php?e=1
11:15 briocalter: oh, exceeded size
11:16 imirkin_: erm
11:16 imirkin_: wtf are you pasting
11:16 imirkin_: dmesg shouldn't be THAT big
11:16 imirkin_: feel free to cut off the errors after a short while
11:16 imirkin_: i'm more interesting in the first errors than the last (which are often a direct result of the first ones)
11:17 briocalter: sure
11:19 briocalter: http://pastebin.com/NVwQgcGJ
11:20 imirkin_: erm... wtf?!
11:20 imirkin_: 2380 == CB_SIZE. how does it get up to 0x9c400? hm :(
11:21 briocalter: no idea, I've used this card with nvidia proprietary before
11:22 imirkin_: aha, it might happen via nvc0_cb_push
11:22 imirkin_: are you proficient at editing and/or building code?
11:22 imirkin_: 0x9c400 = 640000 ... i tend to find such round numbers suspicious :)
11:22 briocalter: never done with anything video related, but I can try
11:23 imirkin_: not necessarily video-related, but if i e.g. ask you to make a small edit to mesa and build it, will you be able to?
11:23 briocalter: btw I'm not on mesa upstream
11:23 imirkin_: yeah, but that code hasn't changed in ages
11:24 briocalter: I can do that, sure
11:24 imirkin_: ok, in mesa, in nvc0_transfer.c, comment out the line in nvc0_init_transfer_functions that says "nvc0->base.push_cb = nvc0_cb_push;"
11:25 imirkin_: (i.e. prefix the line with //)
11:25 imirkin_: and rebuild/install
11:25 briocalter: haha, that's funny, I know how to comment :)
11:25 imirkin_: i like to be thorough :p
11:26 imirkin_: make sure to build with --enable-texture-float otherwise you don't get GL3
11:26 imirkin_: this is what i do: ./configure --prefix=~/install --with-dri-drivers=i965 --with-gallium-drivers=nouveau,swrast --enable-gallium-llvm --enable-gles1 --enable-gles2 --with-egl-platforms=drm,x11 --enable-texture-float
11:27 imirkin_: and then use LD_LIBRARY_PATH=/home/me/install/lib to use my versions
11:28 avph: hi is that bug possibly related to this: https://bugs.freedesktop.org/show_bug.cgi?id=90276 ?
11:29 imirkin_: which bug is "that bug"?
11:29 avph: the one your talking about
11:29 imirkin_: no
11:29 avph: k
11:36 briocalter: goddamn, does mesa requires python-mako module to build?
11:38 imirkin_: it might, i'm a bit annoyed at all those dumb deps =/
11:38 Karlton: I know the latest git does
11:38 Karlton: 5.7 shouldn't
11:38 briocalter: yea, fedora has 404ed me on python-ipaddress
11:38 briocalter: can't install mako easily
11:39 Karlton: use pip or easy_install if you have pyhton2-setup-tools installed
11:40 Karlton: I think for me it was 'easy_install-2.7 -U mako'
11:43 briocalter: nice, that did it
11:43 imirkin_: briocalter: ok cool. obviously that's not a proper fix, i'll put something together
11:44 briocalter: no wait
11:44 briocalter: just building
11:44 imirkin_: oh
11:44 imirkin_: Karlton: just pushed a change to fix terasology
11:45 Karlton: imirkin_: it is in mesa now?
11:45 imirkin_: Karlton: not any release, but i just pushed it upstream like 30s ago
11:46 Karlton: imirkin_: nice, thanks! ^^
11:47 briocalter: imirkin_, is X restart needed?
11:47 imirkin_: briocalter: nope
11:48 hakzsam: imirkin_, Hey, welcome back :)
11:48 imirkin_: hakzsam: thanks ;)
11:49 hakzsam: imirkin_, did you see this patch http://lists.freedesktop.org/archives/mesa-dev/2015-June/085921.html ?
11:50 imirkin_: hakzsam: yeah, but i forgot about it. are drv stats not a thing at all on nv50?
11:50 imirkin_: hakzsam: nouveau_buffer also collects stats fwiw
11:51 briocalter: imirkin_, didn't work, same behaviour
11:51 hakzsam: imirkin_, we collect some of them but they are not exposed through the HUD
11:51 imirkin_: briocalter: bleh ok. so it must just be creating a huge constbuf using the "usual" methods, despite the fact that the driver doesn't allow it
11:52 imirkin_: briocalter: in nvc0_state_validate.c:nvc0_constbufs_validate
11:52 imirkin_: briocalter: can you print out nvc0->state.uniform_buffer_bound[s] and nvc0->constbuf[s][i].size ?
11:52 imirkin_: (right before the PUSH_DATA's that send them into the fifo)
11:53 briocalter: need more arcane mana to cast that
11:53 imirkin_: hm?
11:53 briocalter: just tell me how :)
11:53 imirkin_: so you can comment out lines, but this is getting too heavy? :p
11:53 briocalter: hehe ya
11:53 briocalter: do we need gdb here?
11:54 imirkin_: printf("************ ubo size: %x **********\n", nvc0->state.uniform_buffer_bound[s]);
11:54 briocalter: ok
11:54 imirkin_: and the obvious thing for the other vlaue
11:54 imirkin_: actually give them slightly diff prints so that we know which is which
11:54 briocalter: that will print on dmesg?
11:54 imirkin_: no
11:54 imirkin_: stdout
11:54 briocalter: k
11:56 imirkin_: you're looking for prints with anything >= 0x10000 in it
11:58 imirkin_: briocalter: btw, can i run this application myself? that might speed up debugging
11:59 briocalter: sure, rebuilding
12:00 briocalter: http://zdoom.org/wiki/Compile_ZDoom_on_Linux
12:00 imirkin_: do i also need some sort of map/etc file?
12:01 briocalter: yea, you need a wad
12:01 briocalter: can get the shareware
12:02 imirkin_: ok. so one other thing you can do is make an apitrace that includes the failure and make it available somehow
12:02 imirkin_: that will allow me to see all the GL calls being made
12:02 imirkin_: (https://github.com/apitrace/apitrace)
12:03 briocalter: ok, but first answer me this: console is not outputting the printfs after running the app
12:04 imirkin_: but you're still seeing those errors in dmesg?
12:04 briocalter: I do
12:04 imirkin_: must mean it's something else
12:04 imirkin_: or you messed up
12:05 imirkin_: at this point the apitrace might be easiest
12:05 briocalter: ok lemme try that
12:11 Karlton: imirkin_: I wonder if FlightGear does the same thing that Terasology does: http://i.imgur.com/i49R1Dn.png :)
12:11 imirkin_: Karlton: maybe. does it get fixed with master?
12:12 Karlton: i'll see...
12:14 briocalter: imirkin_, got a trace here
12:14 briocalter: is it pastable on pastebin?
12:14 imirkin_: no
12:14 imirkin_: gdrive... or filebin or something
12:14 imirkin_: xz -9 it
12:15 imirkin_: first verify that replaying the trace (with glretrace) causes the same problems
12:15 imirkin_: otherwise it's all moot :)
12:19 briocalter: yea, apitrace is not able to replay the trace...
12:19 briocalter: lemme try something here
12:21 briocalter: nope, dunno what to do =/
12:23 imirkin_: uhm, what does it say?
12:24 briocalter: it just shows black screens
12:24 imirkin_: is that not what you "normally" see?
12:24 imirkin_: most importantly, do you still see errors in dmesg?
12:24 briocalter: no, it shows garbled graphics, I can imgur it
12:24 imirkin_: it might just be clearing its textures first
12:25 briocalter: yes, replaying the trace shows the same errors on dmesg
12:25 imirkin_: ok perfect
12:25 imirkin_: make it available somewhere
12:25 briocalter: ok sec
12:27 briocalter: https://drive.google.com/file/d/0B5zFVV8gOfs7d3ZLT2VoZWNzYzQ/view?usp=sharing
12:27 imirkin_: cool thanks
12:27 briocalter: thank you, hope it helps
12:28 imirkin_: hmmm... i get all black replaying it on i965
12:28 briocalter: yes same here
12:29 imirkin_: ok, so i see the same errors here. yay.
12:33 Karlton: imirkin_: Terasology is fixed now but FlightGear has some other issue: http://i.imgur.com/i49R1Dn.png
12:34 imirkin_: Karlton: yeah, not too surprising
12:34 imirkin_: Karlton: make an apitrace ;)
12:40 imirkin_: briocalter: hm, looks like they're just feeding regular ubo's that are just bigger than what the driver allows
12:40 imirkin_: briocalter: there's a commit floating around that will enforce that sort of thing at the state tracker level, but i guess the driver should also be defensive
12:40 briocalter: uh, nice to known
12:41 imirkin_: so it's a gzdoom bug
12:41 imirkin_: but that doesn't really make it ok for nouveau to do bad things, so i'll fix that up shortly
12:42 briocalter: glad to help
12:42 imirkin_: not sure why this would work on the blob driver, it has the same limits
12:42 imirkin_: perhaps gzdoom takes a different path internally
12:42 imirkin_: or perhaps it doesn't REALLY want a 640k buffer
12:42 imirkin_: and the blob driver gracefully discards everything past 64k
12:42 briocalter: yea that sounds reasonable
12:45 imirkin_: briocalter: http://hastebin.com/uyadafofah.coffee
12:45 imirkin_: that "fixes" the errors for me, but it still doesn't work
12:50 briocalter: imirkin_, it seems that applying that patch, compiling and installing isn't replacing old mesa
12:50 briocalter: that's why I can't printf earlier
12:51 imirkin_: briocalter: LD_LIBRARY_PATH=/path/to/new/install/lib
12:53 briocalter: same, libs have been installed on /usr/local/lib/dri
12:54 imirkin_: LD_LIBRARY_PATH=/usr/local/lib
12:54 imirkin_: pushed that fix out btw
12:54 briocalter: no dice =/
12:54 imirkin_: Karlton: how's that flightgear trace coming?
12:55 imirkin_: briocalter: did you "make install"?
12:55 briocalter: sure
12:55 briocalter: checked the folder, all there
12:55 imirkin_: is it a 32-bit game whereas you built 64-bit libs?
12:55 briocalter: nope, full 64
12:55 imirkin_: hmmmmmm
12:55 Karlton: imirkin_: I got the trace but I suck at making it >50MB
12:55 imirkin_: how about
12:55 imirkin_: LD_LIBRARY_PATH=/usr/local/lib glxinfo
12:56 imirkin_: Karlton: filebin :)
12:56 imirkin_: don't worry about reducing it
12:56 imirkin_: it's hard and error-prone
12:57 Yoshimo: i guess there is still no word from nvidia about the firmware needed for the 980 model yet?
12:57 tobijk: Yoshimo:
12:57 tobijk: no
12:58 briocalter: yea, glxinfo shows mesa 10.7.0-devel no prob
12:58 imirkin_: briocalter: hmmmm
12:58 tobijk: whereas we'd start to need it, more and more people have those cards showing up here :/
12:58 imirkin_: are you sure you applied the patch?
12:58 briocalter: yep, rebuild and install
12:58 tobijk: btw, imirkin_, wb! :)
12:58 imirkin_: tobijk: thanks :)
12:59 Yoshimo: tobijk: i didn't expect that, i mean such a highend card is usually for people running demanding games that don't run on linux that well
12:59 tobijk: Yoshimo: its not that is the final step, its the first to get those cards woking sadly
13:00 Yoshimo: sad decisions of that company, but well, buying amd isn't gonna fix this
13:08 hakzsam: imirkin_, are you going to have some time to review my series which implements nouveau-perfkit, btw?
13:16 imirkin_: hakzsam: mmmmm... i know nothing about that stuff
13:17 imirkin_: hakzsam: it was all st work, right?
13:17 hakzsam: imirkin_, yeah, it's a gallium state tracker
13:18 imirkin_: i've never used cupti beyond running your test programs :)
13:18 hakzsam: this series implements perfkit not cupti ;)
13:19 imirkin_: i think i've aptly demonstrated my lack of familiarity with the situation
13:22 hakzsam: mupuf, you are going to be the only one guy who wants/can review this series :)
13:26 imirkin_: hakzsam: is there a short synopsis of what it is, are there applications that use it, etc?
13:26 hakzsam: imirkin_, otherwise, I'll submit a RFC which exposes global performance counters for nv50 and nvc0 in few weeks. I'm pretty sure you'll be able to review it ;)
13:27 imirkin_: only at a high level
13:27 imirkin_: i have no idea how all that stuff works
13:27 hakzsam: no problem
13:28 hakzsam: imirkin_, well, you can find a GL sample which uses the API if you download nvidia-perfkit
13:29 imirkin_: what does it do?
13:29 imirkin_: (the api, not the sample)
13:29 hakzsam: http://cgit.freedesktop.org/~hakzsam/libperfkit/ --> this is the wrapper library (like libvdpau) with lot of unit tests to understand how the API works
13:30 hakzsam: https://hakzsam.files.wordpress.com/2014/05/openglharness-screenshot.jpg
13:30 imirkin_: how is this different than glQueryStuff?
13:30 hakzsam: the api allows to monitor graphics performance counters
13:31 hakzsam: what do you mean by glQueryStuff?
13:31 imirkin_: i mean i don't forget the exact gl calls :p
13:32 imirkin_: glBeginQuery/glEndquery
13:33 imirkin_: i guess it's not great for large quantities of counters
13:34 hakzsam: yes probably, and glQueryStuff does't support multi-passes events I think
13:34 hakzsam: this api is designed for NVIDIA's hardware only
13:35 hakzsam: and according to the license/copyright, we have to use it only with nvidia products...
13:40 hakzsam: imirkin_, but I don't know if other applications use it, except the GL sample provided by NVIDIA
13:40 hakzsam: anyways, it seems to be the only way to expose multi-passes events because both the HUD and AMD_perfmon doesn't support them
14:00 Karlton: imirkin_: FlightGear trace: http://expirebox.com/download/4e13b6d4e688e5c618c6e548d973d4c3.html
14:01 imirkin_: Karlton: that's some pretty major fail :(
14:02 Karlton: imirkin_: major fail?
14:02 imirkin_: looks like total ass
14:03 airlied: imirkin_: btw I fixed some of the worse missing prime features :-)
14:03 airlied: and got i915 to fix the rendering problems
14:03 imirkin_: airlied: awesome, i saw some of those
14:03 imirkin_: airlied: now just need to be able to slave multiple outputs from a single gpu
14:03 Karlton: imirkin_: I just see green stuff
14:03 imirkin_: Karlton: oh, i don't see green at all. but i have a GK208.
14:03 imirkin_: Karlton: i see what looks like compression fail, but i thought we fixed that :)
14:03 airlied: imirkin_: that should work
14:04 imirkin_: airlied: i thought it didn't...
14:04 airlied: I slaved hdmi and DP on nvidia from an intel
14:04 imirkin_: is it "new" that it works?
14:04 airlied: imirkin_: no it worked in X server 1.17
14:04 imirkin_: 1.17 is pretty new
14:04 imirkin_: :p
14:04 airlied: to be it's ancient hitsory :-P
14:04 imirkin_: hw cursors is definitely very appreciated
14:05 imirkin_: rotation is a nice little cherry on top
14:05 airlied: now if someone could find out why kwin still givs black windows with offload sometimes
14:05 airlied: though maybe dri3 will solve that
14:05 imirkin_: dri2 fail
14:05 imirkin_: driN+1 will fix all those problems
14:05 imirkin_: and introduce a whole lot more new ones :)
14:06 imirkin_: but don't worry -- driN+2 is on its way!
14:07 imirkin_: Karlton: well on the bright side, disabling compression doesn't fix things.
14:07 imirkin_: i hate debugging issues like that
14:07 imirkin_: of course on the down side is that i have no clue why it's having issues
14:08 Karlton: imirkin_: do you remember off the top off your head what the variable is to play it using software rendering?
14:08 imirkin_: LIBGL_ALWAYS_SOFTWARE=1
14:08 imirkin_: it renders ok with i965
14:08 imirkin_: althought it complains *very* loudly about incorrect fog
14:09 imirkin_: so i suspect it's something relating to that
14:09 Karlton: okay, ty
14:09 imirkin_: of course fog belongs to those things i haven't the foggiest idea about
14:10 imirkin_: seems to work fine with llvmpipe
14:11 Karlton: it shows up when I turn Atmospheric Light Scattering on
14:12 imirkin_: that sounds like fog :)
14:28 kisisten: hi, i have an issue with connecting an external monitor to my laptop, as soon as I connect the external monitor the system freezes up
14:32 imirkin_: kisisten: you have the nv3x right?
14:32 kisisten: yes
14:32 kisisten: one sec, I can tell you the exact model
14:33 imirkin_: can you ssh into the system?
14:33 imirkin_: meh, don't really care about exact model
14:33 kisisten: one sec I can try that also
14:33 kisisten: i doubt it though
14:33 imirkin_: if you can ssh in after the screens die, may be some interesting messages in dmesg
14:34 kisisten: there is a some nouveau errors even without the screen
14:34 kisisten:rebooting the laptop
14:36 imirkin_: a lot of "errors" can be innocuous though
14:39 kisisten: this is my dmesg before external monitor >>> http://pastebin.ca/3028955
14:41 imirkin_: yeah, that's not strictly-speaking bad
14:42 imirkin_: i should fix that error once i figure out a proper way of doing it
14:42 imirkin_: apparently you can't have width=1 height > 1 render targets.
14:51 kisisten: this is after I attache the external monitor >> http://pastebin.ca/index.php
14:51 imirkin_: wrong link?
14:51 kisisten: bahh
14:52 kisisten: http://pastebin.ca/3028963
14:52 kisisten: this should be it, ssh still works
14:52 imirkin_: that's just super... looks like it goes into a loop calling the same scripts over and over :(
14:53 imirkin_: can you file a bug including these logs as well as your vbios (/sys/kernel/debug/dri/0/vbios.rom)
14:54 kisisten: sure, this is on debian jessie
14:54 kisisten: do I fire it to debian or nouveau?
14:54 imirkin_: yeah, i doubt that's related. although mention the kernel version you're using
14:55 kisisten: roger
14:55 imirkin_: bugs.freedesktop.org xorg -> Driver/nouveau
14:55 imirkin_: [not really an xorg issue, but there's no DRM/nouveau component]
14:56 kisisten: a few more lines just came it
14:56 kisisten: came in
14:56 kisisten: http://pastebin.ca/3028969
14:58 kisisten: after a few minutes of being kind of frozen, KDM resets back to the login screen
14:59 imirkin_: do you get use of your 2nd screen?
15:01 kisisten: meaning, do I see things there?
15:01 imirkin_: yes
15:01 imirkin_: actually a boot with like
15:01 imirkin_: nouveau.debug=debug drm.debug=0xe would be interesting
15:02 imirkin_: it won't fix anything, but would likely provide additional info
15:02 kisisten: sure, it's in span more i believe, so if I boot with the screen attached, I can see both screens, I can see the KDM login screen, but when I put in the password KDE never loads to the end
15:02 kisisten: it just sits there with the fancy icons
15:03 imirkin_: i guess that's a little shy of perfection...
15:03 imirkin_: i'm guessing the two issues are related
15:03 imirkin_: kwin tries to do something that greatly upsets nouveau
15:04 imirkin_: do you have compositing enabled?
15:05 kisisten: sry, not sure what that means in this context
15:05 imirkin_: in kwin
15:05 kisisten: compositing
15:05 imirkin_: there's an option
15:05 imirkin_: "enable gl compositor" or something
15:05 imirkin_: make sure it's disabled
15:05 kisisten: in KDE settings?
15:05 imirkin_: ya
15:05 kisisten: one sec
15:05 imirkin_: sorry, not sure exactly where or what it's called, i don't use kde
15:07 kisisten: let me see if i can find it
15:07 imirkin_: https://en.wikipedia.org/wiki/KWin#Compositing
15:07 imirkin_: you want to flip to xrender
15:08 kisisten: comes to think of it, i think it's default for kde i think
15:09 kisisten: xrender that is
15:11 kisisten: nope, it's set to OpenGL 2.0
15:12 kisisten: what about Qt graphics system? Native or Raster?
15:12 imirkin_: that's most unfortunate since nv3x doesn't actually expose GL 2.0, only GL 1.5
15:13 imirkin_: (although it's questionable whether it couldn't easily be made to... i need to re-check what all ARB_texture_npot requires and what the hw has support for)
15:15 kisisten: ok, i think I got it set to xrender, it complained about some things failing
15:18 kisisten: well it's not freezing now, but I don't get the second screen either
15:18 kisisten: xrandr shows two monitors but KDE shows only one
15:19 imirkin_: can you pastebin xradnr output?
15:21 kisisten: one sec
15:25 kisisten: I'll be back, need to reconnect from the laptop in question, for some odd reason xrandr is complaining about putty
15:25 imirkin_: DISPLAY=:0 xrandr
15:28 kisisten: back now
15:28 imirkin_: you could have done DISPLAY=:0 xrandr
15:28 imirkin_: chances are the display wasn't set when you ssh'd in
15:33 kisisten: http://pastebin.ca/3028982
15:34 imirkin_: hmmmm
15:34 kisisten: hmm, now kde sees the second monitor , but it's blank now
15:34 imirkin_: well it thinks that it's supplying a 1280x1024@60 mode to your monitor
15:35 kisisten: that's fine, it's a 19" dell lcd
15:35 kisisten: the problem is, it's not supplying anything :)
15:36 kisisten: the screen is blank
15:36 imirkin_: does the lcd say "no signal"?
15:36 kisisten: in powersave mode
15:36 imirkin_: hrmph
15:36 kisisten: nope, it's not
15:36 imirkin_: dunno.
15:36 kisisten: the lcd is getting something, but it just sits in powersave mode
15:36 imirkin_: is it literally a vga connector?
15:37 kisisten: let me rboot i guess
15:37 imirkin_: or is it a combo dvi connector (i.e. analog + digital)?
15:37 kisisten: reboot
15:37 kisisten: imirkin_: yes it is a blue vga connector
15:37 imirkin_: kk
15:37 kisisten: this laptop only has vga out and the lcd dell screen only a vga in
15:38 imirkin_: :)
15:38 imirkin_: well there's a phantom DVI-D connector
15:38 imirkin_: i figured it might be a misdetected situation where it's actually a single DVI-I connector
15:38 imirkin_: but i guess not
15:39 kisisten: could be, it's a laptop so, the card might have a dvi also, but there is no phisical out
15:43 kisisten: how can I set this up to be a mirror not a span?
15:43 imirkin_: xrandr --output VGA-1 --same-as LVDS-1
15:51 kisisten: thanks imirkin_
15:51 kisisten: after the reboot I have both monitors working
15:51 imirkin_: heh ok
15:51 imirkin_: just have to reboot enough times ;)
15:51 kisisten: the quetion is, what to do now, should I file a bug to nouveau maintainer in debian?
15:52 imirkin_: well there are a bunch of diff issues here...
15:52 imirkin_: like why does the GL compositor shit its pants
15:52 kisisten: to make sure composition is set to xrender?
15:52 imirkin_: well, you don't want to do that for all nouveau
15:52 imirkin_: just the super-crap-old gpu's
15:53 kisisten: hmm
15:53 kisisten: how can I help then, do you still need me to open a bug?
15:54 imirkin_: meh...
15:54 imirkin_: your issue is resolved
15:54 imirkin_: that width/height situation thing is on my to-do list to fix
15:55 imirkin_: (virtual to-do list and it's of infinite length, so...)
15:55 kisisten: got you, so there should be a note somewhere, well maybe there is already, that for crap old kind please set the compositor to xrender or opengl 1.5
15:55 imirkin_: you could see if debian has some sort of list like that
15:55 imirkin_: check if the GL1.5 thing works
15:55 kisisten: one sec
15:56 kisisten: is there a difference with xrender or opengl 1.5?
15:56 kisisten: i mean performance wise
15:57 imirkin_: dunno
15:57 imirkin_: i don't use kde
15:59 kisisten: sorry, thre is 3.1, 2.0 or 1.2 opengl settings
15:59 kisisten: there
16:01 imirkin_: made a card for that rt size issue: https://trello.com/c/rSkJkO0m/104-nv30-can-t-render-to-width-1-height-1
16:04 imirkin_: tobijk: didn't you add OP_CVT support for constant folding? did i never push your patch??
16:06 tobijk: imirkin_: uhm i added it, why it was never pushed, dunno, maybe there where outstanding issues...i really cant remember
16:06 tobijk: let me dig the patch out of my pile of mess ;-)
16:08 tobijk: imirkin_: https://git.thm.de/tjkl80/mesa/commit/6d4dc24fe0703454753d2f88478c661f195bce5c
16:08 tobijk: it would need a rebase though
17:19 imirkin: tobijk: did you at any point verify the saturate behaviour with non-float dest types?
17:20 imirkin: tobijk: i know we generate such converts, but i don't remember ever personally verifying that such behaviour "worked"
17:21 imirkin: tobijk: either way, i think it should be moderately simple to not have quite so much code there... i'll play with it
17:23 tobijk: imirkin: mh does it get usable now in any way?
17:23 imirkin: hm?
17:23 tobijk: i try to remember which path would hit that
17:23 imirkin: oh, there are some float->u16 conversions
17:23 imirkin: which have saturate turned on
17:24 imirkin: or float->u8? i forget
17:24 imirkin: anyways, seems like you could easily handle it all in just 4 cases
17:24 imirkin: float->float, float->int, int->float, int->int
17:25 imirkin: (float to float can happen with f64, but you can't deal with an f64 dest at this point)
17:25 imirkin: i guess i know what most of the constraints are, so i should just write the code
17:26 imirkin: you probably feel like you're wading in a sea of arbitrary rules coming out of nowhere that i keep throwing at you :)
17:26 tobijk: kind of, yeah
17:27 tobijk: i found the old thread about it :D
17:29 tobijk: the saturate was hit with:
17:30 tobijk: uniform sampler2DArray foo;
17:30 tobijk: texelFetch(foo, ivec3(1, 2, 3));
18:03 briocalter: imirkin, sorry to bother you, I got the game running with the compiled mesa just fine now (was a problem on the executable script). The warnings on dmesg are gone, but I still only see garbled graphics. The earlier values that you requested are BOUND: ubo size: 100 and CONSTBUF: ubo size: 10000, dunno if still relevant
18:22 briocalter: http://imgur.com/aBEWr7q