01:47 karolherbst: mupuf: k, I think I am done with the sensor calibration stuff :)
01:56 karolherbst: didn't expect that the effect is so big
01:56 karolherbst: without calibration: nve6: 17.44-18.43 nvc8: 28.46-30.48
01:56 karolherbst: *sampling
01:57 karolherbst: with sampling: nve6: 17.64-17.73 nvc8: 29.10-29.18
05:16 Yoshimo: karolherbst: it wasn't necessary to open a new bug, guess i am victim of https://bugs.freedesktop.org/show_bug.cgi?id=91526
06:10 heiko: hello
06:11 heiko: how can I make me debian packages from mesa master git ?
06:12 imirkin: i think you're looking for #debian
06:12 heiko: yep ok
10:16 SaveTheRobots: hi, is there a way of building nouveau out-of-tree (against 4.5.0 in this case) ? the instructions on the homepage point to a git repo that's horribly out of date :(
10:16 SaveTheRobots: (sorry if this is a regularly asked question, my google-fu is failing me)
10:59 karolherbst1: SaveTheRobots: yeah
10:59 karolherbst1: SaveTheRobots: what gpu do you have by the way?
11:00 karolherbst: SaveTheRobots: the upstream repository is here: https://github.com/skeggsb/nouveau
11:01 karolherbst: SaveTheRobots: but I have some branches for stable clocking on kepler and maxwell1
11:01 karolherbst: SaveTheRobots: well maxwell1 is still testing and needs to checked, but it might work just like kepler in the end
11:02 SaveTheRobots: hi karolherbst, i'm running a 780 Ti (GK110B, NVF0 i think?)
11:02 karolherbst: ahh
11:02 karolherbst: then you should use mine
11:02 karolherbst: because I am sure you _want_ to reclock
11:02 SaveTheRobots: definitely :p
11:02 SaveTheRobots: thanks dude
11:02 karolherbst: SaveTheRobots: Tom^ got pretty good performance with his 780 ti
11:03 karolherbst: SaveTheRobots: https://github.com/karolherbst/nouveau
11:03 karolherbst: SaveTheRobots: branch stable_reclocking_kepler_v2
11:03 karolherbst: just follow the instruction on the wiki page, and make sure to have the new thing loaded
11:03 SaveTheRobots: awesome, i'll give this a go now
11:04 SaveTheRobots: i'm running git master mesa/libvdpau/drm atm, is this recommended?
11:04 SaveTheRobots: i would be running kernel master branch but i've found an automount bug :(
11:06 Yoshimo: wonder how long it will take NVIDIA to allow us to play with maxwellv2 and reclocking
11:06 karolherbst: SaveTheRobots: ohh right way
11:06 karolherbst: SaveTheRobots: my branches are based on 4.4
11:06 karolherbst: but you can simply git rebase them on master
11:06 karolherbst: Yoshimo: mhh well it will take some time
11:06 karolherbst: Yoshimo: more firmware stuff
11:06 karolherbst: Yoshimo: and maybe the falcons are different
11:07 karolherbst: but I doubt the later
11:07 Yoshimo: hopefully not as long as the maxwell firmware release ;)
11:08 karolherbst: SaveTheRobots: and I am stupid, because I rebased all my stuff on 4.5 recently...
11:08 karolherbst: so yeah, it should just work
11:08 SaveTheRobots: karolherbst: git rebase your master branch against kernel master?
11:08 SaveTheRobots: and yeah, it jsut compiled fine :p
11:08 SaveTheRobots: /bin/sh: scripts/mod/modpost: No such file or directory#
11:08 SaveTheRobots: apart from that
11:08 karolherbst: ohh mhh
11:08 karolherbst: did you compile inside drm?
11:08 SaveTheRobots: yup, as per wiki
11:09 karolherbst: k
11:09 karolherbst: as long as there is a nouveau.ko inside drm/nouveau/
11:09 SaveTheRobots: there isn't
11:09 SaveTheRobots: shall i cd ..;make ?
11:09 karolherbst: no
11:10 karolherbst: you need your kernel sources stuff installed
11:10 SaveTheRobots: i do, i've make oldconfig;make prepare against the kernel source
11:10 karolherbst: mhh
11:10 karolherbst: but are you running that kernel?
11:11 karolherbst: SaveTheRobots: usually you are good to go when you just install the kernel sources through your package manager
11:12 SaveTheRobots: i'm running slackware and am custom compiling most things outside of the package manager :p
11:12 SaveTheRobots: and it seems i just need to compile modpost
11:12 SaveTheRobots: (in 4.5 kernel tree)
11:12 karolherbst: yeah but are you running the kernel inside the tree you compiled?
11:13 SaveTheRobots: yup
11:13 karolherbst: ahh k
11:13 SaveTheRobots: i'm ok to compile nouveau out of kernel tree right? i don't need to add it as a remote or anything?
11:14 karolherbst: no
11:14 karolherbst: it just works
11:14 karolherbst: you just need to add the nouveau module though
11:14 karolherbst: inside /lib/modules/$kernel_whatever
11:14 karolherbst: there is somewhere a nouveau module
11:14 karolherbst: you have to replace it
11:15 karolherbst: and if you use initramfs
11:15 karolherbst: you also have to update that
11:15 SaveTheRobots: no initramfs, and yeah, i'll replace the module, drop to terminal, rmmod and modprobe the new one
11:16 karolherbst: something like that
11:16 karolherbst: well you have to stop X and unbind the vtconsole
11:18 SaveTheRobots: unbind via sysfs right?
11:19 karolherbst: /sys/class/vtconsole/
11:19 karolherbst: one is the right one
11:24 karolherbst: SaveTheRobots: well when everything works well you should have a file named boost under /sys/kernel/debug/dri/p
11:24 karolherbst: /sys/kernel/debug/dri/0
11:31 SaveTheRobots: karolherbst: thanks dude, i just rebooted in the end :p
11:31 SaveTheRobots: everything is working nicely
11:31 SaveTheRobots: is stable_*_v2 where dev happens then?
11:34 SaveTheRobots: i'm running kde plasma 5 master, should i use kwin's glx or egl backend?
11:35 SaveTheRobots: gtkperf is slower now, probably doesn't mean a whole lot for real world performance though...
11:51 karolherbst: SaveTheRobots: no, it is just my branch where I try to make kepler reclocking stable
11:51 karolherbst: skeggsb repository is the main thing
11:52 karolherbst: SaveTheRobots: so I guess you could write 0f into pstate and it works stable?
11:55 SaveTheRobots: john@subgenius:[/sys]: find . -name '*pstate*'
11:55 SaveTheRobots: ./devices/system/cpu/intel_pstate
11:55 SaveTheRobots: ./devices/system/cpu/intel_pstate/num_pstates
11:55 karolherbst: SaveTheRobots: /sys/kernel/debug
11:56 Tom^: is volts fixed in that branch ?
11:56 karolherbst: Tom^: yeah
11:56 Tom^: cool
11:56 SaveTheRobots: karolherbst: ahh ok, i'm missing some kernel config options then, probably
11:56 SaveTheRobots: i stripped debug options out
11:56 karolherbst: you need debugfs
11:56 karolherbst: and then you have to rebuild nouveau
11:57 SaveTheRobots: ok thanks, i'll do that now
11:57 Tom^: cant he set pstate as a module option ?
11:58 Tom^: perhaps not
11:58 karolherbst: Tom^: not anymore
12:01 SaveTheRobots: stupid question maybe but can i safely remove nouveau from 4.5 kernel then compile out-of-tree version after?
12:02 SaveTheRobots: (so long as drm/drm_helper/etc are enabled)
12:02 SaveTheRobots: i don't need to compile nouveau in normal tree then out of tree again straight after?
12:04 Tom^: well you dont necessarily need nouveau, besides that you might be dropped into a lowres framebuffer on boot :p
12:06 Tom^: doesnt hurt to have a fallback module tho when shit borks
12:09 SaveTheRobots: lol true :p
12:10 SaveTheRobots: john@subgenius:[~]: sudo find /sys/kernel/debug/ -name pstate
12:10 SaveTheRobots: /sys/kernel/debug/dri/0/pstate
12:10 SaveTheRobots: /sys/kernel/debug/dri/128/pstate
12:10 SaveTheRobots: /sys/kernel/debug/dri/64/pstate
12:10 SaveTheRobots: woop
12:12 karolherbst: SaveTheRobots: you need ttm
12:12 karolherbst: but that isn't selected when you don't compile radeon or nouveau
12:12 SaveTheRobots: ah ok
12:17 Yoshimo: Tom^: yea i noticed that resolution change
12:17 linkmauve1: Nouveau seems to set encoder->possible_clones to 0 on Linux 4.4 and it breaks my encoder detection code, is there a reason it does that?
12:18 karolherbst: SaveTheRobots: so you can try to push 0f into pstate
12:18 karolherbst: if you cat it, it shows you the current clock in the last line :)
12:19 SaveTheRobots: 07: core 324 MHz memory 648 MHz
12:19 SaveTheRobots: 0a: core 324-692 MHz memory 1620 MHz
12:19 SaveTheRobots: 0d: core 549-1176 MHz memory 7000 MHz
12:19 SaveTheRobots: 0f: core 549-1176 MHz memory 7000 MHz
12:19 SaveTheRobots: AC: core 324 MHz memory 648 MHz
12:19 SaveTheRobots: i'll try now
12:19 Tom^: echo 0f | sudo tee /sys/class/debug/dri/0/pstate
12:19 Tom^: and behold awesome fps :p
12:20 SaveTheRobots: niiiice :D
12:20 SaveTheRobots: AC: core 1046 MHz memory 6999 MHz
12:21 SaveTheRobots: fan has spun up, i assume i'll need to manually manage pstates myself?
12:21 SaveTheRobots: i.e. 0a when not gaming?
12:21 Tom^: depends if dynamic reclocking went into that branch, otherwise its a WIP and will come at some point. ask karolherbst
12:22 SaveTheRobots: ok, and for desktop use, shall i go for 07 or 0a ?
12:22 SaveTheRobots: i guess test both and see?
12:23 Tom^: *shrug* i simply just used 0f at all times, the fan or power use didnt bother me :P
12:23 SaveTheRobots: haha ok
12:24 karolherbst: SaveTheRobots: well with sensors you can watch your gpu sensors
12:24 SaveTheRobots: was just about to install lm_sensors :p
12:24 karolherbst: SaveTheRobots: there is a second file named boost
12:24 karolherbst: with boost you can limit the maximum clock
12:25 karolherbst: currently it is a bit limited, because nouveau doesn't care about power consumption yet
12:25 karolherbst: and it might consume too much
12:25 Tom^: is there any card that actually can?
12:25 Tom^: i somehow get the feeling that nvidia have made their card quite safe unless you start to fiddle with the vbios
12:26 RSpliet: Tom^: part of that is driver safety nets
12:26 SaveTheRobots: karolherbst: ok sweet, thanks very much, i'll just manually switch pstates for now, that doesn't bother me
12:26 RSpliet: but there's definitely some crass last-resort thermal protection on there
12:26 karolherbst: Tom^: there are hardware and software safty switches
12:27 Tom^: mmh
12:27 karolherbst: Tom^: if the hardware decides something is really wrong, it might just doesn'r respond anymore
12:27 karolherbst: RSpliet: yeah, but I was talking about power consumption. thermal isn't the problem
12:27 RSpliet: karolherbst: doesn't it blantly slash the clock in half like the good old days?
12:27 karolherbst: for thermal, yes, but power?
12:27 karolherbst: who knows
12:27 Tom^: would be fun to test and see what actually happends
12:28 RSpliet: well, part of the deal is the power budgets in the AGP/PCIe space
12:28 Tom^: but in worst case expensive :(
12:28 karolherbst: did any nouveau dev _ever_ suceeded in consuming more power than the power budgets?
12:28 RSpliet: not sure how they are enforced
12:28 karolherbst: yeah
12:28 karolherbst: this is one problem
12:28 karolherbst: I don't feel like trying out myself
12:28 RSpliet: could be a waste of PSU :-P
12:28 Tom^: because even i at 1.2V which is a max set by vbios at higher clock then nvidia blob on windows sets on boost only nearly reached the power budget :P
12:29 Tom^: and the 780ti is a quite power hungry beast ;)
12:29 karolherbst: yeah I know
12:29 RSpliet: but given how most GPUs don't have that power measurement hardware on it
12:29 RSpliet: it remains best-effort as far as the driver is concerned
12:29 karolherbst: I think it only matter when you run some stuff which really can use all the hardware at the same trime
12:29 karolherbst: *time
12:29 karolherbst: right, only mid-end cards and higher have those usually
12:29 RSpliet: NVIDIA might have some models for that built into their driver
12:30 RSpliet: to translate clock + temperature + voltage to an estimated power consumption
12:30 karolherbst: mhh
12:30 karolherbst: well this doesn't work quite well though
12:30 RSpliet: but just as well they might just apply the bridge-builders principle when creating GPUs
12:30 karolherbst: on full load my gpu power consumption ranges fro 30W to 65W
12:31 Tom^: my kitchen lamp uses more
12:31 Tom^: =D
12:31 karolherbst: :D
12:31 karolherbst: well it is just a laptop gpu
12:31 RSpliet: karolherbst: and PCIe + single plug can deliver... 100W?
12:31 karolherbst: the highest voltage is like 1.02V
12:31 karolherbst: RSpliet: mxm
12:32 karolherbst: RSpliet: but pcie slot can deliver 75W for gpus
12:32 karolherbst: has to actually
12:32 karolherbst: x16
12:32 karolherbst: x8 can be capped at 25W
12:32 RSpliet: MXM-B is capped at 100W
12:32 karolherbst: yeah
12:32 karolherbst: I am sure I have MXM-B
12:33 karolherbst: because A only has 55W
12:33 karolherbst: and this would be quite difficult
12:33 RSpliet: so there still is 30% headroom at 100% load
12:33 RSpliet: no need to worry about frying a PSU :-D
12:33 karolherbst: :
12:33 karolherbst: D
12:33 karolherbst: ohh
12:33 karolherbst: my AC adapter has like 250W
12:33 karolherbst: ohh wait
12:33 karolherbst: only 180W
12:34 karolherbst: but if you think about it: CPU maxes at 57W, gpu at 80W...
12:34 karolherbst: there isn't much room left
12:35 karolherbst: Tom^: one thing though, with my branch the pstate file might report higher clocks than actually clocked too
12:36 Tom^: even the old branch?
12:36 karolherbst: which is normal, because nouveau is already smarter than nvidia here
12:36 karolherbst: no
12:36 karolherbst: I found one card where nvidia showed like 1350MHz, but highest clock was 1080MHz
12:36 Tom^: ok good. because its the old branch i got the wicked performance from, havent quite tested the new one with volts etc.
12:36 karolherbst: it will deliver a little bit higher perf if you switch too boost 2
12:37 karolherbst: otherwise less
12:37 Tom^: boost didnt exist at that time, i ran at max clock offered from the table which was sort of the max boost :P
12:37 karolherbst: right
12:37 Tom^: or well the highest clock under the volt limits
12:38 Tom^: all your boost changes, volts etc i merely only tried to see if it worked or not
12:38 Tom^: never benchmarked it, and now on NSA 10 its quite hard to run nouveau
12:39 SaveTheRobots: karolherbst: do the clock speeds for each pstate have any logic behind them? i.e. is 07 low power, 0a for desktop use, 0f for gaming, etc?
12:39 karolherbst: SaveTheRobots: not really
12:40 karolherbst: pstates usually are for not fine grained clocking domains
12:40 karolherbst: like video/memory/pcie
12:40 karolherbst: in the end it will be automatic depending on the load
12:40 karolherbst: for normal desktop usage 07 should be more than enough with your gpu though
12:41 SaveTheRobots: ok cool, there's a 3-5W difference and 3C difference between 07 and 0a for me, with a pretty nice boost in 2D performance, so i guess 0a seems like a good desktop pstate for me
12:41 SaveTheRobots: ahh ok
12:41 karolherbst: yeah, could be that 0a gives you a smoother experience cause of the higher memory clock
12:42 Tom^: funnily enough i never used below 0f or max perf on blob either because the blob couldnt vsync properly with it so movies and desktop composition teared.
12:42 karolherbst: ....
12:42 karolherbst: well
12:42 karolherbst: sometimes compositors are really smart
12:42 karolherbst: and drop vsyncing when the gpu is not fast enough
12:43 Tom^: perhaps
12:43 karolherbst: well kwin does this
12:43 karolherbst: except when you explicitly disable it
12:43 Tom^: im affected by it in windows too, have to go into nvidia settings and set max perf here too :P
12:43 karolherbst: ...
12:43 karolherbst: those crappy drivers
12:43 Tom^: indeed
12:43 SaveTheRobots: i have to enable full repaints in kwin to get vsync under nouveau, i assume this is typical? automatic doesn't seem to cut it
12:43 karolherbst: we really should fix those flickers on reclock
12:43 karolherbst: SaveTheRobots: use automatic
12:44 Yoshimo: nouveau has a long way to go until it beats these crappy drivers in every aspect
12:44 SaveTheRobots: i get tearing with automatic :(
12:44 karolherbst: SaveTheRobots: but yeah, "only when cheap" is a bad bad bad idea
12:44 karolherbst: SaveTheRobots: ohh mhh
12:44 karolherbst: SaveTheRobots: could be that the nouveau ddx isn't as good as the intel one
12:45 SaveTheRobots: ahh ok :(
12:45 karolherbst: or maybe it is a DRI3 thing
12:45 SaveTheRobots: i'm using the latest master ddx build
12:45 karolherbst: I run a DRI3 only setup somewhat
12:45 SaveTheRobots: ah
12:45 SaveTheRobots: i guess full repaints are my best option then?
12:45 karolherbst: yeah
12:45 karolherbst: I used it before automatic for quite long
12:45 SaveTheRobots: k :)
12:45 SaveTheRobots: btw, are you a KDE user? if so, what editor do you use for coding?
12:46 Tom^: vim master race.
12:47 SaveTheRobots:high fives Tom^ ... after pressing a long and complex key combo to activate the high five mode
12:48 karolherbst: ohh I use nano
12:48 SaveTheRobots: also, in KDE, should i be using GLX or EGL?
12:48 Tom^: you do?
12:48 karolherbst: sure I do
12:48 SaveTheRobots: karolherbst: lies! :p
12:48 Tom^: for real?
12:48 karolherbst: https://gist.github.com/karolherbst/0535f80d3b17d8439c2a
12:49 Tom^: respect to you then. :D
12:49 SaveTheRobots: holy shit :p
12:49 karolherbst: well
12:49 karolherbst: if you set the right options nano is quite nice to use
12:49 SaveTheRobots: i started out with nano when i first started using linux, i loved it, and still do
12:49 karolherbst: you can even copy paste between multiple files with nano
12:49 karolherbst: Tom^: do you know how to do that with vim?
12:50 Tom^: i simply yank and have a X cutbuffer and paste in the other file?
12:50 karolherbst: and if you have to copy paste like 300 lines?
12:51 SaveTheRobots: karolherbst: sorry to nag but is there any recommendation when it comes to GLX vs EGL under KDE ?
12:51 Tom^: i mark it with my mouse and then yank it?
12:51 karolherbst: SaveTheRobots: GLX is more tested
12:52 karolherbst: Tom^: and if there are more lines than your terminal can show?
12:52 karolherbst: or do you do several copy pastes then
12:52 SaveTheRobots: thanks, i guess they should be on par when it comes to performance?
12:52 karolherbst: no idea
12:52 SaveTheRobots: k
12:52 Tom^: karolherbst: then i either resort to googling vim if its capable or simply just cat with grep and tee.
12:53 Tom^: with minor usage of xclip =D
12:53 karolherbst: :D
12:53 Tom^: :3,300y<enter>
12:53 karolherbst: well with nano you can simply do this: nano file1 file2
12:53 Tom^: yanks line 3 to 300
12:53 Tom^: SEE
12:54 karolherbst: then you cut with ctrk+k, closes file and paste with ctrl+u and are done
12:54 karolherbst: yay, fancy vim commands :D
12:55 Tom^: :>
12:55 karolherbst: never actually take my time to learn it
12:55 karolherbst: it's on my todo list of stuff I will do at some point
12:55 Tom^: i mostly only use it because of its plugins
12:55 Tom^: https://camo.githubusercontent.com/1f3f922431d5363224b20e99467ff28b04e810e2/687474703a2f2f692e696d6775722e636f6d2f304f50346f6f642e676966
12:55 Tom^: the youcompleteme plugin, code completion <3
12:56 Tom^: and colorization tuned to the language used, for methods variables etc
12:56 Tom^: but yes its fancy commands can be a bit tough at times
15:08 karolherbst: SaveTheRobots: and any issues yet?
15:13 SaveTheRobots: karolherbst: not yet, although i haven't tested much yet, i'm about to compile 32bit mesa+drm and then fire up Steam :]
15:15 imirkin: oh that reminds me i need to look into that WoW text situation
15:17 karolherbst: would be nice. I kind of feel that the oblivion issue I have is the same thing
15:17 imirkin: does reverting that commit fix it?
15:18 karolherbst: which commit?
15:18 imirkin: the one in the bug
15:18 imirkin: d68226087c
15:18 imirkin: where i re-enable BGRA4 support
15:18 karolherbst: ahh I could try that out
15:27 karolherbst: imirkin: as it seems it does not
15:28 imirkin: so then unlikely to be related.
15:28 karolherbst: "message: major api error 3: GL_INVALID_ENUM in glRenderbufferStorage(internalFormat=GL_SLUMINANCE8_ALPHA8)" is this somewhat important?
15:30 imirkin: nope.
15:30 imirkin: that's wine.
15:30 imirkin: i complained to them, they didn't seem to care too much
15:30 karolherbst: k
15:30 imirkin: and it's, in fact, not a big deal
15:30 imirkin: it's part of their format checking logic when internalformat_query2 isn't supported
15:31 karolherbst: any idea how I could debug my issue? check what format the textures have that doesn't get displayed?
15:31 imirkin: find the draw that goes wrong, figure out what makes it special
15:32 karolherbst: ohh the trace is nice, not many calls
15:52 karolherbst: imirkin: k, the texture object is already corrupted
15:52 karolherbst: GL_SRGB8_ALPHA8 format
15:55 imirkin: so figure out where it comes from
16:08 karolherbst: k, I think I found the place where the texture is generated/loaded/whatever
16:09 karolherbst: @1 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_SRGB8_ALPHA8, width = 64, height = 64, border = 0, format = GL_BGRA, type = GL_UNSIGNED_SHORT_4_4_4_4_REV, pixels = NULL)
16:09 karolherbst: does that sound right?
16:10 imirkin: oh fun. so also RGBA4
16:11 karolherbst: mhh
16:11 karolherbst: guess what
16:11 karolherbst: I replayed the apitrace after reverting the patch
16:11 karolherbst: ...
16:11 karolherbst: I guess I should have rerun the game?
16:11 imirkin: shouldn't matter
16:11 imirkin: internally that'd get all mapped to RGBA8 or whatever
16:12 imirkin: oh, pixels = null
16:12 imirkin: so actually the RGBA4-ness doesn't matter
16:15 karolherbst: mhh
16:15 karolherbst: on intel the texture is just blank white
16:15 karolherbst: actually fully transparent
16:17 karolherbst: on nouveau it looks like this: https://i.imgur.com/tHFU3z8.png
16:17 imirkin: i guess it's not getting cleared?
16:18 karolherbst: it is black before
16:19 karolherbst: ohh wait
16:19 karolherbst: 1x1 black, that doesn't count I suppose
16:19 karolherbst: well it does glGenTexture, glBindTexture, 2x glTexParameteri then the glTexImage2D call
16:24 karolherbst: and then glBindTexture, glPixelStorei, glTexSubImage2D, glPixelStorei
16:25 karolherbst: and after that nouveau still shows the same corruption
16:25 karolherbst: but on intel the texture is there instead if the full alpha texture
16:27 karolherbst: @1 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0, yoffset = 0, width = 64, height = 64, format = GL_BGRA, type = GL_UNSIGNED_SHORT_4_4_4_4_REV, pixels = [binary data, size = 8 kb])
16:29 karolherbst: the binary data looks okayish
16:38 imirkin: heh
16:39 imirkin: are you looking at the WoW trace or the oblivion trace?
16:39 imirkin: coz that's precisely the conclusion i also came to for WoW
16:39 karolherbst: oblibion
16:39 imirkin: ok, so then it's the same issue
16:39 karolherbst: k
16:43 karolherbst: what I find somewhat weird is, that the glTexSubImage2D call doesn't change the texture at all
16:48 imirkin: yep
16:48 imirkin: that's my observation too
16:54 karolherbst: mhh maybe some issue with the memory?
16:55 karolherbst: like does something stupid when there is no pixels
16:56 imirkin: not sure what you mean
16:58 karolherbst: maybe no memory is allocated and the stuff points to some random thing or something
17:02 karolherbst: k
17:02 imirkin: bo is allocated at miptree creation time
17:03 karolherbst: imirkin: turning the gpu on and off changes the texture
17:03 imirkin: of course
17:03 imirkin: the vram is uninitialized
17:03 karolherbst: okay and unninitialized also means we can't write stuff into it?
17:04 imirkin: no, we can write stuff
17:04 imirkin: it's like malloc'd memory
17:04 imirkin: it contains whatever happens to be there
17:04 karolherbst: okay, but why doesn't the glTextsubImage2D call changes anything?
17:04 imirkin: therein lies the issue :)
17:04 karolherbst: one thing though
17:04 imirkin: if i knew, i'd have solved the issue already
17:05 karolherbst: everytime I run the trace, the texture looks the same
17:05 imirkin: yeah, coz the same piece of vram gets allocated
17:05 imirkin: since the allocator is pretty deterministic
17:05 imirkin: and you don't have much else going on on that gpu
17:05 karolherbst: right
17:12 karolherbst: I'll try to debug this with gdb... will take 2 days until I reach nouveau code I guess
17:15 imirkin: hehe
17:16 karolherbst: at least I get the right call
17:18 karolherbst: try_pbo_upload is important?
17:18 karolherbst: I suppose
17:21 karolherbst: ohh wait, it goes somewhere else
17:23 karolherbst: imirkin: anything I should read out for you while debugging?, I am currently inside nvc0_miptree_create
17:23 imirkin: nope
17:24 imirkin: either you're debugging it or i am
17:24 karolherbst: ohhh
17:24 karolherbst: src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c:291
17:24 karolherbst: there is this if, if, if thing
17:24 karolherbst: guess what
17:24 karolherbst: none condition was met
17:24 karolherbst: expected or not?
17:24 karolherbst: bo_config.nvc0.memtype is 0, no idea if that's bad
17:28 karolherbst: well I can only assume that the stuff is written, but just somewhere else
17:28 karolherbst: it looks okayish to me, but I have no big idea what is going on there anyway
17:31 imirkin: memtype = 0 means that it's an untiled (aka linear) texture
17:31 imirkin: i wonder if it's getting a buffer texture and the 2d engine doesn't know how to handle that properly?
17:32 karolherbst: mhh, currently I am in nvc0_blit_3d
17:34 karolherbst: info->dst.box.depth is 1, does that sound right?
17:38 imirkin: yes.
17:39 imirkin: is dst's memtype != 0?
17:39 karolherbst: in nvc0_blit_3d?
17:39 imirkin: ya
17:41 karolherbst: mhh just need to know how I get that out of the struct pipe_resource
17:42 imirkin: nv04_resource(res)->bo.memtype
17:43 karolherbst: no member named memtype
17:45 karolherbst: nv04_resource(dst)->bo.config.nvc0.memtype is 254
17:45 karolherbst: but I have no idea if that is what you wanted
17:48 imirkin: yeah
17:48 imirkin: 0xfe
17:48 imirkin: i think that's like the default color surface tiling memtype
17:48 imirkin: unless there are complicating circumstances like MS, etc
17:48 imirkin: (nvc0_miptree.c has the logic)
17:58 karolherbst: I think I will gonna head to bed. I can't find something terrible wrong there and it seems like the stuff is copied somewhere