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