00:50mupuf: karolherbst_work: New version. And this time, I took a video of it, for the presentation :p
00:50mupuf: wait, is this a joke or what?
00:57mupuf: yes, I managed to send the wrong patch ... again!
02:43imirkin: skeggsb: ping
02:43skeggsb: imirkin: hey
02:44imirkin: skeggsb: a few questions ...
02:44imirkin: (a) to get NV25 3d class working on nv34, in *theory*, i just need to add the right class to the gr/nv34.c?
02:45skeggsb: on the sw side, yes. i'm not sure if the hw requires anything different
02:45imirkin: ok. i guess i'll find out in due time.
02:45imirkin: hmmm... i had more questions... gimme a sec
02:45imirkin: oh right. kernel api's.
02:46imirkin: so for KHR_robustness
02:46skeggsb: (note: i've been away on PTO all last week, and only back today, so, got some catching up to do :))
02:46imirkin: have you thought about what the kernel needs to provide at all?
02:46imirkin: ah! that explains why pings last week went unanswered
02:47imirkin: and, separately from the KHR_robustness stuff, have you had any further thoughts on changes necessary for vulkan? (or even just good to have ...some sort of fence fd thing seems like a good idea so you could select on it or some of the usual bs so we don't have to invent new api's around it)
03:33skeggsb: imirkin: hm, looks like it's just the reset notification stuff yeah?
03:33skeggsb: the vbo access safety etc is dealt with by the 3d class methods to restrict the range i belive
03:34imirkin: it's just the reset notification
03:34skeggsb: as for vulkan, i have a large chunk of mm work i got context-switched away from, which i should be able to get back to soon (i should be posting the atomic/mst patches in the next few days)
03:35imirkin: oh nice!
03:35skeggsb: that work is also almost done, so i can't imagine it'll be too long before it follows
03:35skeggsb: the userspace interfaces to it, need more thought, because it'll likely require some thinking about pushbuf submission / fence handling etc too
03:36imirkin: right ... well strictly speaking i don't think any of that is _necessary_, but definitely helpful
03:37imirkin: i haven't fully thought it through though
03:37skeggsb: yes, aside from splitting the physical/virtual representation of buffers, the rest is "nice to have"
03:37skeggsb: it's all inter-related to some extent though
03:38imirkin: yeah ok. would be nice to get GL 4.5 up and running - KHR_robustness functionality is required for that
03:39imirkin: i might be able to weasel something out though
03:39imirkin: i think it has an option for "dunno, maybe something happened, maybe not, maybe stop asking me"
03:52BoRiS: Hi guys
04:36BoRiS: I just checked out a fresh copy of Mesa compiled from git with nouveau to get vdpau support [I have the firmware] for my NVIDIA GPU ION (GT218) [NVA8] and it seems when using using mplayer and force vdpau, it seems that mplayer freezes at the first few frames and just freezes there. If I play with basic x11 [non vdpau], it plays fine. I think theres a regression.
04:37imirkin: hm, i remember some screwup around that
04:37imirkin: anything interesting in dmesg?
04:39imirkin: what was it ... i think something mesa related.
04:39imirkin: ah right. commit 38fcf7cbadc in mesa
04:40imirkin: should be included in mesa 11.2.2 and 12.0.1
04:40imirkin: you said you're using mesa from git... are you sure that your vdpau library was updated properly?
04:40imirkin: if you're using LD_LIBRARY_PATH, that won't work
04:41imirkin: you have to set VDPAU_DRIVER_PATH or something like that
04:41BoRiS: When I do a vdpauinfo, it shows the info
04:43BoRiS: Im running the latest 4.7.2 kernel
04:45imirkin: ok, so decoding is actually working but then freezes. great.
04:45imirkin: oh, i bet it's the dri3 thing
04:45imirkin: vdpau recently got dri3 support
04:45imirkin: i think that's somehow broken with nouveau
04:45imirkin: try running it with LIBGL_DRI3_DISABLE=1 in env
04:46BoRiS: k, I'll do it right now
04:46imirkin: er hm
04:46imirkin: might need to apply that first
04:46BoRiS: k, let me do that now
04:49BoRiS: Applying commit https://github.com/imirkin/mesa/commit/6029ea74621e3f8abd94de6f473531dcf33398da to a fresh copy of Mesa from git and compiling.
04:55BoRiS: done recompiling
04:58BoRiS: testing it out
04:59BoRiS: first setting LIBGL_DRI3_DISABLE=1
05:05BoRiS: attempting to play a video
05:06BoRiS: still freezes the video
05:06BoRiS: Starting playback...
05:06BoRiS: Movie-Aspect is undefined - no prescaling applied.
05:06BoRiS: VO: [vdpau] 624x352 => 624x352 Planar YV12
05:06BoRiS: Movie-Aspect is 1.77:1 - prescaling to correct movie aspect.
05:06BoRiS: VO: [vdpau] 624x352 => 624x352 Planar YV12
05:06BoRiS: A: 0.2 V: 0.0 A-V: 0.129 ct: 0.000 2/ 2 ??% ??% ??,?% 1 0
05:07BoRiS: export | grep GL
05:07BoRiS: declare -x LIBGL_DRI3_DISABLE="1"
05:07imirkin: bah =/
05:11BoRiS: dmesg | grep nouveah and Xorg.log file here. http://pastebin.ca/3704819
05:13imirkin: i haven't the faintest clue why it's failing :(
05:13imirkin: does it work ok with mesa 12.0?
05:13imirkin: or older kernels?
05:13imirkin: you're going to have to do some digging to figure out wtf changed
05:14BoRiS: I'll try Mesa 12.0
05:17BoRiS: Just tried Mesa 11.2.2 and its still not working.
05:19BoRiS: Im also testing to downgrade the kernel 4.6.5
05:19BoRiS: I'll also build 11.1
05:24BoRiS: Tried on 4.6.5 kernel and still nothing. Finishing compiling build 11.1.0
05:27BoRiS: hmm, still freezes on 11.1.0
05:27BoRiS: btw: Im also using Xorg from the latest git too.
05:29BoRiS: I'll try testing some more older mesa versions and older kernels and log back in tommorrow at 5:30pm/17:30 CST
05:29BoRiS: give you an update
09:25kloofy: well technical stuff was asked, lets pretent we are on radeon, cause i have not yet read the nvidia tiling specs, it allows to set constant cached memory location or even from sgpr's the pixmap descriptor in a packet, so the descriptor will be some 0xfxxxx reg
09:26kloofy: now what is needed to be sent along with that is tiling information which are held in specific other mmio regs
09:27kloofy: now that shader can communicate with ring buffer via constant cache or some sgpr, ring buffer polls the reg specified by shader from that slot and writes back a mask
09:28kloofy: shader knows that hey this is the mask i wanted for that instruction, and to get around the performance with ineffecient tiling which would be random, it can rewrite the physically tagged index bits i.e the physical location
09:29kloofy: you load the exec mask and execute the instruction and control flow is managed via branching hack, row of patents for this one
11:43karolherbst: mupuf, RSpliet: I thought RSpliets talk can't be at friday? or is 9:05 okay or did something changed?
11:49MarkedOne: Hello... I have optimus enabled laptop... and I found solution to use bumblebee.. but it is not working.. karolherbst_work told me not to use bumblebee and pointed me here https://nouveau.freedesktop.org/wiki/Optimus/. But I am lost.. what should I do? Let say I want to use my dedicated graphic card for wine and blender
11:50mupuf: karolherbst: : Shit, you are right!
11:50mupuf: RSpliet: can you confirm? Since you gave no instructions like this in your proposal
11:51Calinou: MarkedOne: Nouveau is only really worth it if you have working reclocking
11:51Calinou: what's your graphics card model?
11:51Calinou: else, just go for NVIDIA blob + Bumblebee
11:53MarkedOne: this is output of 'lspci -vvv' 01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 520M] (rev ff) (prog-if ff) !!! Unknown header type 7f
11:53karolherbst: MarkedOne: as I said: update your kernel :p
11:53karolherbst: ohh wait
11:53karolherbst: that was another one
11:54MarkedOne: karolherbst: nvm :) anyway my kernel is Linux NB-DEBIAN-ACER-01 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux
11:54MarkedOne: Calinou: I don't know what is reclocking...
11:55karolherbst: MarkedOne: you are better of with your intel gpu, cause the nvidia one will perfom _really_ bad with nouveau
11:55Calinou: shit cards like this one are not really worth anything
11:55karolherbst: so bad, it ain't fun _at_all_
11:55Calinou: even with NVIDIA blob, you won't gain much performance
11:55karolherbst: Calinou: still better than the GF119 520M :D
11:56MarkedOne: karolherbst: How do you know my Intel GPU is more powerfull than nvidia one?
11:56karolherbst: sure "similiar to desktop 440", what a crap card was the 440?
11:56MarkedOne: Calinou: What is worng with my card? Is it too old?
11:57karolherbst: MarkedOne: because under nouveau, the gpu will urn at lowest clocks
11:57karolherbst: which is slow
11:57karolherbst: terribly so
11:57Calinou: old and terribly low-end
11:57karolherbst: MarkedOne: just bad support from nouveau side
11:57karolherbst: we can't change the memory clocks on fermi gpus
11:58MarkedOne: Calinou: But probably still better than integrated from Intel? Or am i wrong?
11:58MarkedOne: karolherbst: Can I ask why? Is it long term problem?
11:59karolherbst: it ain't easy
11:59karolherbst: MarkedOne: well if if you have a low end intel gpu and the nvidia one is 2x+ faster, good driver support vs bad driver support can easily make that difference disappear
12:01MarkedOne: so what should I do? I am not going to buy new laptop soon... And want to get maximum from that shitty HW i have..
12:03karolherbst: I guess your only choice is nvidia then
12:03karolherbst: or help out with reclocking support :)
12:06MarkedOne: I would really like to help with reclocking :) Please point me.. But I am not sure if i can help >/
12:06karolherbst: ask RSpliet about how you can help then
12:08Calinou: you probably need programming experience for that
12:12MarkedOne: Calinou: I have programming experiences. Im not noob...but also not expert... Maybe I could help..
12:13Calinou: generally you need to be an hardcore C programmer to help Nouveau, not a newbie PHP/Python programmer like me :P
12:15MarkedOne: Calinou: I have some experience with C... but nothing big yet..
12:16MarkedOne: RSpliet: Hello, I would like to ask you. How can one help with nouveau reclocking problem?
12:18karolherbst: Calinou: :O sure not
12:19karolherbst: "hardcore C" dev is a silly term anyway
12:24MarkedOne: hmm.. he isn't here probably
12:43Calinou: karolherbst: by "hardcore C developer", I mean someone who wrote a simple OS/kernel or something like that
12:43Calinou: or a simple game engine
12:43Calinou: or an esolang
12:46karolherbst: I didn't do any of those
12:56RSpliet: MarkedOne: I think right now it's difficult to contribute
12:56RSpliet: I have a lot of pieces of the puzzle already, and fail to pick out one or two
12:58MarkedOne: so you are responsible off putting things together.. and you are overwhelmed?
13:01RSpliet: MarkedOne: responsible is a big word, I'm a volunteer in my spare free time
13:03RSpliet: I've done this before for GT21x, GT200, NVIDIA ION and various GT(X)9x00, it's just a choir that requires time
13:05RSpliet: if you happen to have a way to reliably extract the PMU firmware from a Fermi GPU that'd be very helpful
13:12karolherbst: RSpliet: I will most likely implement that stuff over the weekend or so, cause I will kind of need it too
13:24karolherbst: or do you want to do that for fermi? I want to do that for kepler+ to RE the pmu interface anyway, so it is your choice
13:28kloofy: https://www.google.com.au/patents/US7617384 https://encrypted.google.com/patents/US6629188 http://www.google.us/patents/US8035648 http://www.google.com/patents/US20110072213
13:29kloofy: 4 patents what we talked about, it's all written there for fermi and keplers sake , but on nv50 final patent does not apply it does not have CCTL instruction, instead it has PUSH and PULL methods for the ring stuff
13:33kloofy: the thing with the cache seems to be that on AMD there are flags to make cache accesses coheraet access CU's for l1 or the writes would have to be invalidated, l2 is coherant by default there
13:34kloofy: but..on nvidia going with the PUSH and PULL stuff, it's known that l1 on nvidia is not coherent , so probably it needs to use instructions to invalidate
13:40RSpliet: RSpliet: if the implementation works well, I can repeat on Fermi I reckon
13:42kloofy: https://devtalk.nvidia.com/default/topic/520945/cache-data-invalidation-between-kernel-calls/ here is the relevant confirmation, gregory diamos's answer
13:44karolherbst: RSpliet: talking to yourself again?
13:47kloofy: RSpliet: :) hehee, but on fermi and kepler the scheduler can be done in most elegant way, but radeon and nv50 i belive would function the same in the end, but scheduling done slightly differently there, cctl is the most elegant way imo
13:49RSpliet: karolherbst: I'm sure there's some I in a parallel universe listening
13:52karolherbst: RSpliet: did you see our comments about your talk being on friday?
13:52mupuf: RSpliet: are you ok with being scheduled on friday?
13:53mupuf: karolherbst: nice :D
13:53mupuf: same second, we are good
13:53RSpliet: karolherbst: no, didn't see any comments
13:54mupuf: RSpliet: will you be at XDC on friday?
13:54RSpliet: I'm sure I will be
13:54mupuf: very good then :)
13:54mupuf: no issues = mupuf happy
13:54kloofy: so to my knowledge everything is ok, but it's pointless for me to try to play along in the development it's impossible it seems... i'd see what i can do individually better off
13:55RSpliet: I'm sure 45 minutes is too much though
13:55karolherbst: add a 10 minute demo then
13:55mupuf: 30 minutes then?
13:55kloofy: i don't think you have questions when you read kinda https://www.x.org/docs/AMD/old/si_programming_guide_v2.pdf those patents and similar links as to this packet stuff
13:55RSpliet: there's nothing to demonstrate
13:55mupuf: that means we can arrive later :D
13:56RSpliet: "You have 5' and we cut your mic"
13:56RSpliet: what does that mean?
13:56mupuf: RSpliet: it is for lightning talks
13:56karolherbst: cable + scissor = broken cable
13:56mupuf: 5 minutes is the format
13:56mupuf: it is a way to report back
13:57RSpliet: ah so not 5 foot
13:58mupuf: RSpliet: bloody brit :D
13:58RSpliet: fixed a typo for you as well ;-)
14:14kloofy: now i am kind a busy ...please try to understand that the si programming guide, it should show that actually all chips are on the good side, well intel ones too again bit differently happens there
14:16kloofy: that the/the, i need go, bye
15:19karolherbst: mupuf: do you see any reason, why someone is able to flash a modified vbios to a maxwell2 gpu, but we can't fake the vbios through pramin?
15:20karolherbst: mhh wait, they use nvflash for flashing of course
15:20RSpliet: karolherbst: does nvafakebios calculate the checksum over the right size VBIOS, or just the first 64KiB?
15:20karolherbst: will check
15:22karolherbst: vbios * 512
15:22karolherbst: so whatever the second byte is
15:22karolherbst: but yeah, you might be on to something
15:22karolherbst: I think I will try that
15:23karolherbst: read the unmodified vbios, fake it, read it out, diff it
15:29karolherbst: anyway, I don'T really plan on using nvflash on a maxwell2 gpu, yet.
15:29karolherbst: just to figure this thing out
15:43rmrfchik: hi, I have NVIDIA GT215 (0a3180a2), nouveau says NOUVEAU(0): Chipset: "NVIDIA NVA3",
15:44rmrfchik: Firefox claims "Hardware H264 Decoding No"
15:44rmrfchik: while https://nouveau.freedesktop.org/wiki/VideoAcceleration/ states that NVA3 -> VP4.0 and H.264 is supported
15:44rmrfchik: any ideas?
15:45rmrfchik: wait, mesa-vdpau-drivers is missing
15:46karolherbst: maybe blacklisted, who knows :p
15:46karolherbst: ohh, yeah, that might be a valid reason
15:46karolherbst: check vdpauinfo then
15:46rmrfchik: this is what vdpauinfo said
15:47rmrfchik: still no luck :(
15:47rmrfchik: H264_BASELINE --- not supported ---
15:47rmrfchik: hmm, why so
15:51night199uk: is there a more basic intro nvidia memory anywhere than this?
15:52night199uk: karolherbst: re vbios, what happens when you fake the vbios through pramin?
15:52night199uk: i’m obviously building my own nvidia vbios so interested in this
15:56imirkin: rmrfchik: read the page you referenced. all the info should be there.
15:57imirkin: night199uk: the nvidia blob driver reads that vbios from pramin instead of the real one. so we can figure out what the driver does differently in various cases.
15:58night199uk: interesting, this is useful to know
15:58rmrfchik: imirkin: tried to put firmware and reboot, no luck
15:58rmrfchik: will try more tomorrow
15:58night199uk: the vbios for OSX has the capability to cache the vbios ROM into (i guess) PRAMIN
15:58night199uk: so I was curious whether the blob driver for linux/windows actually reads the PRAMIN or the ROM copy
15:59night199uk: one thing I want to toy with is letting people tune various things directly from the BIOS (like you do for e.g. MB clocks)
15:59imirkin: rmrfchik: vdpauinfo is the thing to check, not firefox. who knows wtf firefox does.
15:59night199uk: the generic nvidia VBIOS does not have any shadowing that I can see today
16:00imirkin: night199uk: the vbios might live in any number of places, so it follows a fallback strategy. top of pramin is the first place it looks.
16:00night199uk: but e.g. apple uses this in the apple nvidia cards so that apple can ‘override’ the vbios by including specific vbios roms in their MB BIOS
16:01night199uk: interesting; thats handy to know, saves me some research
16:02night199uk: that means if I mod the vbios driver to let people specify alt. ROMs from the BIOS UI then they would be honored by windows
16:02night199uk: to save people from flashing their cards
16:06RSpliet: rmrfchik: does firefox claim that, or flash?
16:09RSpliet: if the latter, I recall requiring libXv or even libXvMC on Fedora. And in Flash you need to explicitly enable vdpau
16:11siro__: night199uk: where can I find additional information about PRAMIN ?
16:11night199uk: siro__: no idea :-)
16:11night199uk: probably best to ask someone else
16:15siro__: night199uk: the VBIOS should be accessible through ACPI, so PRAMIN might have no effect
16:15night199uk: don’t think that’s the case, right?
16:15night199uk: ACPI would just expose the configuration of the BARs and resources I guess
16:15night199uk: i thought PRAMIN was exposed via one of the BARs?
16:16night199uk: i could be wrong
16:16siro__: there's _ROM to read the VBIOS
16:17siro__: in case it's not implement the driver falls back to other methods
16:18night199uk: does _ROM point directly to the PCI Option ROM?
16:18night199uk: i’d have to look at how _ROM is set up in the bios
16:20night199uk: not my focus yet :-)
16:20siro__: night199uk: yes, as on laptops there's no Option ROM inside the PCI device
16:20night199uk: need to understand pitch and blocklinear first :-)
16:22night199uk: so the windows driver will check _ROM before PRAMIN?
20:32karolherbst: can glamor be apitraced somehow?
20:33imirkin_: apitrace X
20:33karolherbst: ahh nice
20:35karolherbst: imirkin_: any ideas about this? http://matrix.theblob.org/nouveau-screenshots/4.7.0.modded-google.png
20:36karolherbst: I would assume this is a bug somewhere in the glamor/gl stack
20:36karolherbst: but maybe you know anything about this already
20:37Sophira: (That's from me; I should point out that "modded" in this case refers to karolherbst's fork of the nouveau kernel driver, with a mod to only use the first 3 partitions.)
20:37Sophira: (Of the memory.)
20:38imirkin_: karolherbst: glamor + nouveau = fail, at least until fairly recent versions of glamor
20:38karolherbst: yep, it seems X 1.17 is installed
20:38Sophira: (I apologise, btw - that's from xorg 1.17.4, too. Going to go ~amd64 it and install the latest)
20:38karolherbst: imirkin_: X git needed?
20:38imirkin_: nah, 1.18
20:38imirkin_: pretty sure it's a bug in nouveau, but it defeated me
20:39Sophira: Will go for 1.18.4, then.
20:39imirkin_: and then it magically started to work in X 1.18
20:39imirkin_: i didn't ask questions.
20:39karolherbst: the best things
20:39imirkin_: Sophira: you have a maxwell board i assume? otherwise i'd highly advise against the glamor route.
20:40karolherbst: 970 with 4GB ;)
20:40imirkin_: ah excellent.
20:40Sophira: Though with only 3GB being used :)
20:40Sophira: But yes.
20:41karolherbst: I think he knows already :p
20:42karolherbst: no need to feel sorry, I just make silly remarks all the time
20:43Sophira: If I ~amd64 xorg 1.18, I need to manually ~amd64 the individual Xorg drivers used too, right?
20:43Sophira: (I get a conflict with xf86-input-evdev)
20:44karolherbst: not sure
20:44karolherbst: evdev needs to be rebuilt due to Xorg ABI
20:44karolherbst: but I don't think it actually depends on <1.18
20:46Sophira: Hmm. I think you're right. That makes this error a bit odd. Hang on a moment, I'll pastebin it.
20:46imirkin_: iirc x 1.18 is unmasked...
20:46karolherbst: Sophira: add ~amd64 to x11-base/xorg-drivers as well
20:46imirkin_: oh wait no
20:46imirkin_: my bad
20:47imirkin_: this is what i have: http://hastebin.com/yesiparuma.hs
20:47Sophira: karolherbst: Already did, at least the specific version of it.
20:48karolherbst: uhh, odd block
20:48karolherbst: I guess you indeed have to copy imirkin_s thing
20:48karolherbst: well, you can skip llvm
20:49Sophira: The ebuild does indeed have "!<x11-drivers/xf86-input-evdev-2.10.0" in its PDEPEND.
20:49karolherbst: uhh, missed that
21:01netz: whattup o/
21:12Sophira: Okay, the issue's gone after updating to 1.18.4.
21:12Sophira: Thanks for that.
21:12karolherbst: well, that's always the chance with a bit outdated software ;)
21:12Sophira: And sorry for not updating first!
21:13karolherbst: feel free to bug us about any issues you find with your maxwell2 gpu, because chances are there are a lot and we should slowly figure those out, especially because we are really close to reclock maxwells in general as well
21:14Sophira: Sure thing.
21:14imirkin_: note that there have been a bunch of GM20x fixes in mesa-git that aren't in 12.0.x yet
21:15imirkin_: one i happen to remmeber was multisample-related, but there are likely others
21:15imirkin_: not sure why a new 12.0.x hasn't been cut
21:15imirkin_: it's supposed to be every 2 weeks, but it's been 7-8 weeks now...
21:15karolherbst: ping the release manager
21:15imirkin_: i think xexaxo was out for a while, but he's def back now
21:24karolherbst: how can I disassemble falcon code with envydis?
21:25imirkin_: envydis -m falcon -V fuc3 -w
21:25imirkin_: (or fuc5, depending on what you're disassembling)
21:25karolherbst: -w is for that header thing?
21:25imirkin_: no, -w means you'll be feeding it 32-bit words formatted in hex
21:25imirkin_: -i would mean you have a file of the stuff
21:25imirkin_: there are other flags too
21:32Sophira: Quick question - does anyone know a definitive way to tell if DRI3 is in use?
21:35imirkin_: Sophira: LIBGL_DEBUG=verbose glxinfo > /dev/null
21:35imirkin_: libGL: Using DRI3 for screen 0
21:36Sophira: Okay, thanks. That's what I thought :) Seems to be fine then. Just wasn't sure because I wasn't seeing anything about DRI3 in my Xorg.0.log, only DRI2. Thanks :)
21:41Sophira: Here's an interesting thing. When I run glxinfo, every other time I run it it hangs after printing line 0x2ce of the "600 GLXFBConfigs", after only 564 printed.
21:41Sophira: It doesn't seem to be delay-related. It's literally every other time.
21:45karolherbst: mhh, odd
22:48kloofy: i recapped things a bit, allthough i am quite occupied with things, if things remain unclear what was my point, i may be able to do rough pseudo code guidelines, but not the real code at this stage