00:40 medfly: Hi! I heard some (radeon) have requirement for lines being 64byte alignment, is the requirement the same for nvidia hardware?
01:15 fubu: ;)
01:18 mupuf: and I will give up for now
01:19 mupuf: I will try to port my findings to C and integer arithmetics
01:19 fubu: ;p
01:19 fubu: really ?
01:20 mupuf: http://pastebin.com/w6svTvSp it will look like osmething like this
01:26 imirkin: medfly: "lines"?
01:27 medfly: I think framebuffer lines. sorry, I'm very new to this
01:28 imirkin: i think fb addresses have to be aligned to 256 bytes on nvidia
01:28 medfly: oh, thank you.
01:28 imirkin: at least for 3d rendering render targets
01:29 skeggsb: for display too, the lower 8 bits are shifted off the address
01:41 medfly: wooo!! thanks :) it works! (where 'it' is framebuffer on netbsd, it was trying 64byte)
01:43 imirkin: medfly: yay! i assume you're aware of Riastradh's efforts to port nouveau to netbsd?
01:43 medfly: Yes, he's a good friend :) and he succeeded! I'm using it
01:44 imirkin: [and other drivers, as i understand it]
01:44 imirkin: ok cool - just wanted to make sure there wasn't accidental duplication of effort
10:37 mlankhorst: imirkin: there's a bug report for WW_MUTEX
13:13 gordan: Hi. Does nouveau support nvenc functionality these days? I have an aarch64 box on which I would like to use nvenc for H.264 encoding.
13:16 mupuf: gordan: nope, sorry
13:18 gordan: Thanks for the quick answer.
13:18 mupuf: y w
13:50 karolherbst: mupuf: the right answer would have been: "We search somebody who is willing to a project on leveraging the nvenc microchip to increase encoding performance on nouveau driven systems. Might you be willing to work on that?"
14:03 mupuf: hehe
15:01 juninta: RSpliet: hi dude, well remember that actually inter-warp/wave messages are superior method to intra-warp lanemask shuffles and of course also branching
15:03 juninta: todays all gpus almost support those features, nouveau/nvidia cards also when i long time ago read the code, then calim had comments of such, it is nothing special lanes are given backing registers for every warp
15:04 juninta: on nouveau, if someone squeezes out some time to deal with code, then probably fermi and kepler and maxwell and up should implement the sched opcodes
16:47 karolherbst: okay never forget: tomorrow is ticket buying time...
18:40 karolherbst: meh, that 22500 reg is there since fermi
18:40 karolherbst: well
18:41 imirkin: yeah
18:42 imirkin: we use it to not do display stuff in a bunch of places
18:42 imirkin: check devinit/gf100.c for example
18:42 imirkin: [i think - just going by memory]
18:43 karolherbst: mhh, it isn't read on all nvc0
18:44 karolherbst: ohh I see
18:45 karolherbst: okay
18:45 karolherbst: makes sense then
18:46 karolherbst: so if (devinit.disable & NVKM_ENGINE_DISP) touch pdisplay
18:46 karolherbst: uhh
18:46 karolherbst: don't touch
18:47 karolherbst: well, if there would be actually access to it
18:48 karolherbst: ahh device->disable_mask
18:48 karolherbst: odd
18:51 karolherbst: super odd
18:51 karolherbst: my patch should have worked :(
18:54 karolherbst: imirkin: can you explain this to me? https://gist.github.com/karolherbst/f116a3aa38fe47c6b4d1d42270efc5e1
18:54 karolherbst: :/
18:55 karolherbst: 0x022500 is 0x00000201
18:55 karolherbst: nvkm_device_engine(device, NVKM_ENGINE_DISP) should return NULL
18:56 imirkin: right
18:56 karolherbst: except something messes with disabled_mask
18:58 karolherbst: NanoSector: got time for something?
19:07 NanoSector: karolherbst, yeah
19:11 NanoSector: karolherbst, what's up?
19:12 karolherbst: NanoSector: can you run nouveau with the latest patch on the NanoSector_test branch?
19:12 NanoSector: sure, let me get my laptop real quick
19:12 imirkin: karolherbst: my guess is that the writes in question are coming in via vbios
19:13 NanoSector: there we are
19:13 karolherbst: imirkin: what do you mean?
19:13 NanoSector: with the nice fucked up screen
19:13 imirkin: we execute vbios scripts
19:13 imirkin: the vbios scripts might be assholes and have writes to registers that aren't there
19:13 karolherbst: you mean the write to that reg or to 62c000?
19:14 imirkin: yes.
19:14 karolherbst: imirkin: we already solved the memory reclocking problem, I just want to know why we still write to that with stock nouveau
19:14 NanoSector: karolherbst, it's telling me that the git repo is already up to date, are you sure you pushed?
19:14 karolherbst: imirkin: we touch it through the pmu script and we can disable that
19:14 karolherbst: imirkin: then it works
19:14 karolherbst: NanoSector: quite
19:14 karolherbst: ohh wait
19:14 NanoSector: :P
19:15 karolherbst: I guess that's your network having issues :p
19:15 NanoSector: heh thanks, it's in now
19:15 karolherbst: imirkin: here is the hack: https://github.com/karolherbst/nouveau/commit/566cc83556d18ecd00c391ce9a39d714cfca167d
19:16 NanoSector: eh, i should pull too
19:16 imirkin: karolherbst: i doubt that'll help.
19:16 NanoSector: was wondering why make was like 'nope'
19:16 karolherbst: imirkin: well, it did
19:16 NanoSector: lol
19:16 imirkin: really/
19:16 karolherbst: imirkin: yes
19:16 imirkin: what's his 22500 set to?
19:16 NanoSector: allright
19:16 NanoSector: new one inserted
19:16 karolherbst: imirkin: 201 with nvidia
19:16 imirkin:wonders if vbios script writes to 22500
19:16 karolherbst: it is read only
19:17 imirkin: iirc there's also a second register which is user-writable
19:17 karolherbst: maybe
19:17 imirkin: 22540 or something. probably nto exactly that
19:17 karolherbst: if it affects 22500, who knows what happens
19:17 karolherbst: NanoSector: then just reclock and give me dmesg output
19:17 NanoSector: does it matter if i run on battery?
19:17 karolherbst: no
19:17 NanoSector: ok because i'm out of power outlets, lol
19:18 karolherbst: ...
19:18 karolherbst: a reclocked GPU really helps there
19:18 NanoSector: :D
19:18 NanoSector: could turn the heat into power
19:19 NanoSector: 07 works
19:19 NanoSector: 0a works
19:19 karolherbst: yeah, sure
19:19 NanoSector: 0f works
19:19 karolherbst: but I need dmesg
19:20 NanoSector: uploading
19:20 NanoSector: http://sprunge.us/BJWN
19:21 karolherbst: disable_mask 0x82000000
19:21 karolherbst: mhh
19:21 imirkin: it's a 64-bit thing
19:21 karolherbst: sure
19:21 imirkin: i forget what the literal value of DISP is
19:22 karolherbst: meh..
19:22 karolherbst: is the first avlue in a enum 0 or 1 in C?
19:22 karolherbst: 33
19:23 imirkin: 0
19:24 karolherbst: something is wrong here
19:24 karolherbst: he has two things inside 22500
19:24 karolherbst: and two things disabled in the disbale_mask
19:24 karolherbst: ....
19:24 karolherbst: the hell is going wrong
19:24 karolherbst: the other thing is NVKM_ENGINE_CE1
19:25 karolherbst: 26
19:25 imirkin: karolherbst: you're onnly printing 32 bits
19:25 karolherbst: disable_mask should have been 0x204000000
19:25 karolherbst: imirkin: no
19:25 imirkin: oh
19:25 karolherbst: imirkin: %llx
19:25 imirkin: ah ok
19:25 imirkin: NanoSector: do you have nvapeek installed? if so, can you do "nvapeek 22500"?
19:25 karolherbst: NanoSector: do you have envytools somewhere?
19:26 NanoSector: can install it I guess
19:26 NanoSector: hang on
19:27 karolherbst: ohh wait, the first value is inded 0
19:27 karolherbst: so 25 and 32
19:27 imirkin: [nvapeek is part of envytools]
19:28 karolherbst: uhhh
19:28 karolherbst: NVKM_ENGINE_CE_LAST = NVKM_ENGINE_CE5,
19:28 karolherbst: k
19:29 karolherbst: ...
19:29 NanoSector: it says 00022500: 00000201
19:29 karolherbst: imirkin: okay, the value should be right
19:29 karolherbst: hex((1 << 25 ) | (1 << 31))
19:29 karolherbst: 0x82000000
19:29 imirkin: and 25 + 31 are which engines?
19:29 karolherbst: CE1 and DISP
19:31 imirkin: yeah ok
19:32 karolherbst: NanoSector: update the branch again
19:33 NanoSector: karolherbst, it throws warnings, should i ignore?
19:33 karolherbst: yes
19:33 NanoSector: ok, installed
19:33 karolherbst: reclock with that and then a new dmesg
19:35 NanoSector: karolherbst, http://sprunge.us/fUBO
19:36 karolherbst: .....................
19:36 NanoSector: hmm>
19:36 NanoSector: ?
19:37 karolherbst: imirkin: printk(KERN_WARNING "nvkm_device_engine(ram->base.fb->subdev.device, NVKM_ENGINE_DISP) %x\n", nvkm_device_engine(ram->base.fb->subdev.device, NVKM_ENGINE_DISP));
19:37 karolherbst: prints [ 105.353923] nvkm_device_engine(ram->base.fb->subdev.device, NVKM_ENGINE_DISP) 0
19:37 imirkin: seems expected...
19:37 NanoSector: that looks like what you told it to do
19:37 karolherbst: imirkin: printk(KERN_WARNING "disable_mask & NVKM_ENGINE_DISP %llx\n", ram->base.fb->subdev.device->disable_mask & NVKM_ENGINE_DISP);
19:37 karolherbst: [ 105.353922] disable_mask & NVKM_ENGINE_DISP 0
19:37 karolherbst: ...........
19:38 imirkin: did you mean & (1 << DISP) ?
19:38 karolherbst: ohhhh
19:38 karolherbst: :/
19:38 karolherbst: right
19:38 imirkin: almost the same thing :p
19:38 imirkin: 1ULL << DISP, of course
19:38 karolherbst: sure
19:38 karolherbst: okay, so nvkm_device_engine returning 0 is a good thing
19:38 karolherbst: now I wonder
19:39 karolherbst: NanoSector: before I go totally crazy here
19:39 karolherbst: NanoSector: git checkout 775e177e1c11ccd61b9b5af1ae5546bfc20b4286
19:39 karolherbst: ohh wait
19:39 karolherbst: your local changes
19:39 karolherbst: mhhh
19:40 karolherbst: should be fine? no idea
19:40 NanoSector: do i try that commit?
19:40 karolherbst: uhm
19:41 karolherbst: I think I am like super silly now
19:41 karolherbst: ...
19:41 karolherbst: NanoSector: okay, here is what you do
19:41 karolherbst: NanoSector: save your local changes for the clock
19:41 karolherbst: NanoSector: then do the git checkout 775e177e1c11ccd61b9b5af1ae5546bfc20b4286
19:41 karolherbst: apply the patch again if needed
19:41 karolherbst: then use this one
19:42 NanoSector: what do you mean with save changes for the clock?
19:42 karolherbst: that base mhz thing
19:43 NanoSector: oh i already checked out before you sent that, sorry :x
19:43 karolherbst: no worries then
19:44 NanoSector: with the patch you mean remove those 4 lines you mentioned?
19:44 karolherbst: no
19:45 NanoSector: i'm not following, sorry :x I'm not smart
19:45 karolherbst: does git status list clk/base.c ?
19:46 NanoSector: yeah
19:46 NanoSector: oh you already added that patch?
19:46 karolherbst: k then it is fine
19:46 karolherbst: nope
19:46 karolherbst: it survived
19:46 NanoSector: ohh I see
19:46 NanoSector: aight
19:50 NanoSector: karolherbst, http://sprunge.us/IJiF
19:50 karolherbst: aye
19:50 karolherbst: and the world is sane again
19:50 NanoSector: sanity :)
19:51 karolherbst: guess what, that patch to fix it also lands with 4.10
19:51 karolherbst: so with stock it wasn't there to begin with
19:51 karolherbst: ...
19:51 karolherbst: now I feel silly
19:51 NanoSector: oh so we were pretty much hunting something that's fixed in 4.10?
19:51 karolherbst: yes
19:51 NanoSector: oh, i'm so sorry :x
19:51 karolherbst: I fixed it myself by the way :D
19:51 NanoSector: nice :D
19:52 karolherbst: silly waste of time :(
19:52 NanoSector: yeah, i'm sorry
19:52 karolherbst: nah, that's my fault basically
19:52 karolherbst: anyway, that issue with the high clocks still remains
19:52 NanoSector: so basic reclocking works but not boost?
19:52 karolherbst: but I kind of know about this, problem is, it doesn't happen with mine
19:53 karolherbst: I even go up to 1150MHz without issues
19:53 NanoSector: hmm
20:14 udoprog: Hey, I'm wondering about the state of Vulkan support on Nouveau. AFAICT it's currently _not_ on the roadmap. Is this correct?
20:14 imirkin: not on any official roadmap
20:15 imirkin: [there is no official roadmap]
20:15 karolherbst: well everybody is free to help out and work on that
20:15 imirkin: however Ben Skeggs has expressed an interest in making it happen (and he's paid by RH to work full time on nouveau)
20:15 karolherbst: ohh true, he said something
20:16 Yoshimo: what is Ben working on these days?
20:16 imirkin: he just finished making atomic work
20:19 udoprog: imirkin: that brightens the prospects a bit, thanks
20:19 imirkin: it's not like a 1-day project though :)
20:20 imirkin: on the bright side, we did discuss making vk work on nv50 and fermi (not just kepler+)
20:21 udoprog: oh, why nv50 in particular?
20:25 airlied: i suspect fixing nouveau threads will overtake vk
20:26 airlied: since distros not shipping the GL driver is worse than having no vk driver
20:27 imirkin: udoprog: it's the generation before fermi
20:28 imirkin: i believe nvidia only ships vulkan drivers for kepler+ though
20:30 airlied: imirkin: what is the biggest vk affecting thing pre kepler?
20:30 airlied: texture bindings?
20:31 imirkin: airlied: i think so, yeah. but intel did just fine with fixed bindings...
20:31 imirkin: airlied: also there may be some difficulties for nv50 in various shader restrictions. but iirc i looked at it, and it was all supportable.
20:32 airlied: i dont think ill tackle evergreen vk!
20:32 imirkin: your insanity has limits? :)
20:34 airlied: i try to keep how far i stretch the bounds of what RH should be paying for :-)
20:34 imirkin: hehe
20:34 imirkin: vk on r100!
20:34 airlied: should get to gl4.5 finishing at least
20:39 imirkin: that'd be nice
20:40 imirkin: at least GL 4.3 (i.e. up to and including compute/ssbo)
20:43 airlied: i think compute local mem was where i stopeed
20:43 karolherbst: well at least I don't get any threading crashes even when my entire plasma shell is prime offloaded, will try that outpink sink over the weekend
21:36 mykon: got a question, are LCD panels resolution advancing faster than gfx?
21:37 mykon: I am concern that gfx aren't advancing at the same pace of LCD pixel count.
21:38 mykon: although we are getting just 4k, 8k is now ready.
22:26 mooch2: SOFTWARE RENDERED VK
22:26 mooch2: LES GO
22:27 mykon: wut?
22:39 mooch2: i was joking about mesa having a software rendered vulkan driver
22:45 karolherbst: imirkin: well I got more mails because you actually deleted all those attachments :p
22:46 karolherbst: mooch2: well, I doubt this will be in any way useable at all even if we had it
22:46 imirkin: karolherbst: yeah, but they came all at once and were easy to ignore
22:48 mooch2: it's still good for testing tho
22:52 airlied: karolherbst: I've got half of one :-P
22:52 karolherbst: airlied: sure, and how fast is it?
22:52 airlied: it's softpipe
22:52 karolherbst: uhhh
22:53 karolherbst: I meant for vk
22:53 airlied: yup it's softpipe for vk
22:53 karolherbst: ohh I see
22:53 karolherbst: can't imagine that it will be any fast, never tried it though
22:53 airlied: I'd have to add compute shaders to llvmpipe to make it use llvmpipe
22:53 karolherbst: ohh wait
22:53 karolherbst: it isn't public yet, right?
22:53 airlied: oh it's in a branch
22:53 airlied: it's pretty much a vulkan->gallium translator
22:53 karolherbst: yeah sure, but you have like hundreds of branches, right?
22:54 airlied: https://cgit.freedesktop.org/~airlied/mesa/log/?h=not-a-vulkan-swrast
22:54 airlied: I got it to run one or two of the vulkan demos
22:55 karolherbst: airlied: how is this vulkan to gallium translating thing going at all?
22:55 karolherbst: I could imagine there is some kind of CPU overhead overall
22:56 airlied: karolherbst: yeah for a swrast it doesn't really matter
22:56 airlied: since CPU overhead is the rast engine, everything else is noise
22:56 airlied: the code pretty much has to create a CPU command stream
22:56 airlied: that it then executes in a gallium context
22:57 karolherbst: I see
22:57 karolherbst: but I figure nouveau could use the translator as well?
22:57 airlied: it would be a really bad idea for a hw driver
22:58 airlied: since you'd be creating a CPU queue then a GPU queue
22:58 airlied: like you'd defeat most of the point of vulkan
22:59 airlied: since it's about reducing CPU overheads
22:59 airlied: the other option would be adding the vulkan API to gallium, which is just adding an abstraction that isn't that useful in the end
23:00 airlied: I think radv/anv are probably as good as you can, share the compiler + resource layout stuff
23:09 karolherbst: yeah
23:14 airlied:also thinks using nir makes some things easier, but that could be a bit up in the air