00:24 pq: karolherbst, mmiotrace giving "unexpected secondary hit" implies that the caught instruction wasn't fixed by handling just one fault. You'd probably have to look deeper on why it still faults when the iomem page has been put back.
00:26 pq: ..and the BUG is triggered by a different address, no idea about that.
00:27 pq: karolherbst, skeggsb did hit some unhandled instructions, but your case does not seem like that at first hand... or does your trace contain UNKNOWN entries?
00:28 karolherbst: what do you mean by "your trace" there is no trace at all
00:28 pq: karolherbst, so it didn't have chance to write it out?
00:28 karolherbst: nope
00:28 pq: karolherbst, the very least the trace should have the pci info stuff
00:28 karolherbst: just an empty trace with all that header stuff
00:29 pq: no map entries either?
00:30 pq: according to https://gist.github.com/karolherbst/f69e2a7b9c372e049525 there should be a couple of map and unmap entries, but I suppose those didn't manage to get out to user space either
00:30 karolherbst: for that to know I would have to create the trace again, but I think besides the initial stuff there wasn't anything written to it
00:31 karolherbst: well
00:31 karolherbst: some seconds later my entire network is also down
00:32 pq: the last time I even looked at mmiotrace was over 6 years ago I think...
00:33 pq: if not closer to 10
00:34 karolherbst: I only know that it sometimes works for me and sometimes it doesn't
00:34 karolherbst: but I have no clue what I have to change so that it works again
00:34 pq: could it be a driver other than nvidia?
00:35 pq: when mmiotrace gets enabled, it will catch all ioremaps regrdless of driver
00:35 karolherbst: well
00:35 karolherbst: my desktop environment is already fully running :)
00:36 pq: being non-deterministic failure is really sad, since it's not any obvious fault in mmiotrace then, like an unhandled instruction
00:36 karolherbst: well I think it is deterministic, because it doesn't work anymore :D
00:36 karolherbst: and at the time it worked, it worked without issues
00:36 karolherbst: maybe I changed something, but no idea what
01:16 pq: karolherbst, oh, I got the impression it was random. skeggsb said something about some recent version of the blob causing UNKNOWN entries.
01:16 karolherbst: I tried downgrading it as far as I can, but it didn't help
01:16 karolherbst: I tried with 355.11
01:17 karolherbst: but I had this issue before with much older software
01:17 pq: *shrug* :-/
06:21 n7025: i get some strange results after using a fully clean 4.4.0-rc7 kernel from kernel.org
06:22 n7025: xorg log tells me: [drm] failed to open drm device for ..... -19
06:22 n7025: EE open /dev/dri/card0: no such device or directory
06:22 n7025: and dmesg is full of:
06:22 n7025: nvidiafb_setcoloreg start
06:22 n7025: nvidiafb_setcoloreg end
06:22 n7025: nvidiafb_setcoloreg start
06:23 n7025: nvidiafb_setcoloreg end
06:23 n7025: ...
06:24 n7025: have i done something wrong?
07:09 karolherbst: mupuf: your fan patch is inside 4.4 already, but not upstream nouveau :D
07:09 mupuf: karolherbst: ah, good, I did not check there
07:09 mupuf: I guess ben locally updated his branch
07:09 karolherbst: it was there in rc6 I think
07:10 karolherbst: yeah we also looked over some branched of mine this night
07:10 karolherbst: the hwmon stuff and remove_sysfs
07:11 karolherbst: I think he will slowly catch up the next days :)
07:11 karolherbst: ohh and he also looked over the fsrm patch
07:13 mupuf: good! You accumulated a ton of code that should be merged or reworked to get upstream
07:13 karolherbst: mupuf: but he also stated that the fsrm stuff is low priority for him, because he doesn't see why we should check those at all if those values are set by the vbios
07:13 mupuf: yes, it was good work to check that it indeed is set by the vbios
07:13 karolherbst: I think it may be really not needed practically, but I would like to be rather safe here
07:14 karolherbst: well we still have no big clue about this for nvf0+ cards
07:14 karolherbst: because the entire stuff seems different there
07:14 karolherbst: or at least different regs
08:34 imirkin: mupuf: you may be interested in https://github.com/skeggsb/nouveau/commits/master, i think ben has moved over to that repo
08:44 imirkin: mwk: what does sbb do with the carry bit in the nvc0 macro language?
08:44 imirkin: [or adc]
08:47 mwk: adds it to the result
08:48 mwk: ... or maybe subtracts, for sbb
08:48 mwk: either way, the result is that add + adc gives you a 64-bit add
08:49 imirkin: mwk: er what?
08:49 imirkin: mwk: mov $r1 (adc $r2 $r3)
08:49 imirkin: what is in $r1?
08:49 mwk: $r2 + $r3 + carry
08:49 imirkin: how do you set carry?
08:50 mwk: add, adc, sub, sbb set carry
08:50 imirkin: ahhhhhhhh
08:50 imirkin: ok, that makes more sense. thanks :)
08:50 mwk: and maybe some other insns, but I didn't look that deep
08:50 imirkin: sure, that's fine
09:15 imirkin: pmoreau: hakzsam: when you get a chance, take a look at http://patchwork.freedesktop.org/series/2155/ -- make sure that there's nothing too objectionable in there wrt compute support.
09:15 hakzsam: will do this evening
09:18 n7025: the bug here is half solved: https://bugs.freedesktop.org/show_bug.cgi?id=93557
09:18 n7025: please push the already made fix upstream before there is a stable 4.4 kernel with kernel-panic
09:21 n7025: imirkin: you told something about those nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b020 last days. Have you any idea how to fix them?
09:21 imirkin: no, but afaik they pose no threat
09:22 n7025: no speeddown, nothing?
09:22 imirkin: certainly nothing you could ever notice
09:23 n7025: i would still like to help you devs to solve those errors as good as i can :)
09:23 hakzsam: imirkin, ben really moved his repo to github? for which reasons?
09:24 imirkin: hakzsam: that may be a question for ben
09:24 imirkin: hakzsam: believe it or not, but we are actually separate people :)
09:25 hakzsam: imirkin, yeah but maybe he told you that yesterday :)
09:25 hakzsam: skeggsb, --^
09:25 imirkin: he gave me a lame reason like a week ago. i suspect he wanted to get rid of the last vestiges of darktama more than anything
09:27 hakzsam: this might be the reason
10:32 imirkin: anyone around with a kepler and a dolphin build?
10:32 imirkin: preferably a GK10x
10:34 orbea: dolphin as in dolphin-emulator or?
10:34 imirkin: dolphin-emulator
10:34 imirkin: i.e. the thing that emulates dolphins
10:34 orbea: I have a gtx780 ti and dolphin
10:35 imirkin: orbea: hmmmm... kepler2. still good test
10:35 imirkin: orbea: can you grab https://fifoci.dolphin-emu.org/media/dff/fortune_street.dff
10:35 orbea: what could be tested?
10:35 imirkin: orbea: and let me know if it looks totally wrong or not
10:36 imirkin: orbea: i.e. does it look like the left or right side of https://fifoci.dolphin-emu.org/compare/1040188-1038421/
10:37 orbea: looks lkike the right side to me
10:37 orbea: *like
10:37 imirkin: orbea: i.e. the correct-looking side?
10:37 orbea: Yea, looks fine
10:37 imirkin: ok thanks
10:38 orbea: np
10:38 imirkin: would be good to double-check with a kepler1... but i'm tending to think that they messed something up
10:39 orbea: dolphin has been working fine for me since you fixed that issue with the broken text/graphics, maybe a bit slow and it works with alsa poorly
10:40 imirkin: orbea: you could try reclocking :)
10:40 imirkin: orbea: even moving up to 0a should give you a big boost
10:40 orbea: yea, I haven't tried it again since learning how to set that
10:40 orbea: PCSx2 was working a lot better with it though
10:40 orbea: which was already working better than dolphin
10:40 imirkin: orbea: probably a factor of 10x by the time you get to 0f
10:41 imirkin: (faster memory + faster core = faster rendering, who knew)
10:41 orbea: openmw also works really well with it
10:41 imirkin: not sure what that is, but good to know :)
10:42 orbea: Its the free engine for morrowind
10:42 imirkin: oh, that open-source reimpl using the original data files
10:43 imirkin: most things should work well :) there are a few issues i'm aware of... generally applying to newer titles
10:43 imirkin: the biggest one is that people have discovered multithreading
10:44 orbea: yea, most games I have tried with nouveau work well.
10:44 orbea: even without reclocking
10:44 imirkin: that's coz you have a monster gpu :)
10:45 orbea: heh, I went out of my way to get it :)
11:00 imirkin: karolherbst: do you have a dolphin-emu install handy?
11:02 karolherbst: yes
11:02 imirkin: karolherbst: can you grab https://fifoci.dolphin-emu.org/media/dff/fortune_street.dff
11:02 karolherbst: currently no time, but I can check later if you want
11:02 imirkin: karolherbst: and then run it and see which side of https://fifoci.dolphin-emu.org/compare/1040188-1038421/ it corresponds to
11:03 karolherbst: ohh that's an dolphin trace?
11:04 imirkin: yes
11:04 karolherbst: k, I need to update my dolphin anyway then
12:01 uriah: hello
12:02 uriah: i'm wondering, when the PowerManagement status matrix indicates that something is mostly done, can i expect it to be enabled by default in the current stable version of the nouveau driver?
12:02 uriah: or is there some parameter required to enable/test it?
12:02 imirkin: uriah: that matrix isn't super-mega-accurate
12:02 uriah: i'm talking about all the NV30 stuff
12:03 uriah: oh, ok
12:03 imirkin: uriah: is there something in particular you're wondering about?
12:03 uriah: well, just what the status of NV30 code is :)
12:03 imirkin: any specific feature you're wondering about?
12:03 uriah: it says everything is mostly done, except the memory timings which are stalled... is this still accurate, or did someone change that recently?
12:04 uriah: i'm just updating an old machine and hoping that performance will be improved
12:04 imirkin: uriah: afaik there is no functioning reclocking on nv30
12:04 uriah: oh ok
12:05 imirkin: uriah: i did make some minor fixes to mesa a while back that should have made swtnl more reliable... not sure how often it is used in practice
12:05 uriah: even though the status matrix says it's mostly done, basically what's left to do prevents reclocking from working?
12:05 uriah: hmm, ok
12:05 imirkin: no clue tbh
12:06 uriah: do you think it's worth trying to test atm?
12:06 imirkin: test what?
12:07 imirkin: newer kernel? won't hurt.
12:07 imirkin: newer mesa should hopefully improve things too
12:07 uriah: reclocking
12:07 uriah: ok
12:07 imirkin: there is no reclocking support for nv30
12:07 uriah: ok :(
12:07 imirkin: experimental or otherwise
12:07 uriah: so i guess whoever is in charge of the status matrix might want to update it at some point, when they have time :)
12:08 imirkin: what's wrong with the table?
12:08 uriah: it indicates that reclocking is mostly done for nv30 :)
12:08 imirkin: it is.
12:08 uriah: ok
12:08 imirkin: or so i'm guessing
12:08 imirkin: until it's completely done, nothing works though.
12:08 uriah: but no code has been commited?
12:08 uriah: ah ok
12:08 uriah: i see
12:09 imirkin: anyways, i would read "mostly" as "stalled" if i were you in that table
12:09 uriah: ok :(
12:09 imirkin: and "done" as "partially" :)
12:09 uriah: :)
12:10 uriah: good to know, thanks
12:10 uriah: so, "mostly stalled"
12:10 uriah: lol
12:10 imirkin: but when you're putting that table together it's really depressing to mark everything as stalled
12:10 uriah: yeah, true
12:10 imirkin: so you instead give yourself the benefit of the doubt and say "mostly"
12:10 uriah: ok
12:10 imirkin: whereas that's just another way of saying "not done"
12:11 uriah: yeah...
12:12 imirkin: the reality is that unless an interested party steps up, more work on nv30 is very unlikely to happen
12:12 uriah: ah...
12:12 uriah: interested + competent party
12:12 uriah: :P
12:13 imirkin: yes... although the level of competence doesn't need to include "nvidia hw expert"
12:13 imirkin: but one would need to know how to read and write code
12:13 imirkin: not to mention have access to the relevant hw
12:13 uriah: indeed
12:13 uriah: perhaps when i have a bit more knowledge of c i'll give it a try
12:14 uriah: but for now, i must concentrate on another project, which involves learning c
12:14 uriah: ;)
12:14 imirkin: well, there can be less-involved projects
12:14 imirkin: if you're interested in improving things on your nv30
12:14 uriah: like what?
12:14 imirkin: the one i have in mind is around making Xv use drm planes instead of the stupid thing it does now
12:15 uriah: what does it do?
12:15 imirkin: which should make video playback not suck as much
12:15 uriah: heh
12:15 imirkin: well, on nv3x and newer it uses a shader to texture the YUV surface onto RGB
12:15 imirkin: but nv3x isn't well suited for that
12:15 uriah: i see
12:15 imirkin: and older GPUs get the conversion done on the CPU i think
12:15 imirkin: but they all have overlay hardware
12:16 imirkin: where you can just feed a NV12 or YUYV surface and it will display it
12:16 imirkin: no questions asked
12:16 imirkin: and ... i added kernel support for this
12:16 uriah: cool
12:16 imirkin: exposed as drm planes
12:16 imirkin: so now all one has to do is make xf86-video-nouveau make use of it
12:17 uriah: i'll be honest, though, i tend to use my other computer for watching video... this one is more for music (production + playback)
12:17 uriah: but it could be a good exercize
12:18 uriah: tbd
12:19 uriah: i'd also say that it's already a bit high of a challenge for me atm, but you don't learn unless you try... so that's a bogus excuse
12:24 hakzsam: imirkin, I did comment your shader buffer support series
12:24 imirkin: hakzsam: replying
12:28 imirkin: hakzsam: as for the nvc0 multidraw changes, you can look at https://github.com/imirkin/mesa/commits/tmp4 if you're really interested. i'm not particularly expecting anyone to be able or willing to review these.
12:29 hakzsam: imirkin, I like the name of your branch :)
12:30 imirkin: thanks
12:30 imirkin: i try to name my branches with the most suitable name possible :)
12:30 hakzsam: imirkin, well, so you really want to remove compute.c?
12:30 imirkin: hakzsam: not really... but i also don't want to update it
12:31 imirkin: hakzsam: i consider the interfaces that it uses to be invalidated though
12:31 imirkin: and we need to come up with something that works well for both opengl and opencl
12:32 imirkin: given that opencl is theoretical at this point, opengl gets priority imo
12:32 hakzsam: imirkin, what about updating compute.c according to the changes related to the compute/tgsi interface? I would prefer this way...
12:33 imirkin: couldn't test them, and i effectively break nouveau for that sort of usage
12:33 imirkin: and i believe that the clover <-> driver interface will need updating as well
12:35 hakzsam: I agree that GL is *the* priority, we need GL 4.3, but I would prefer to keep those tests
12:35 imirkin: i'm not deleting them
12:35 imirkin: but they will be totally broken
12:35 imirkin: and will need someone to think about how to update the relevant interfaces
12:35 hakzsam: they are totally broken yeah :)
12:36 hakzsam: imirkin, I assume that your changes are also required for arb_shader_image_load_store?
12:36 imirkin: well, my changes def have ARB_shader_image_load_store in mind
12:36 imirkin: but i haven't implemented it
12:36 imirkin: but i expect that images will map to IMAGE[]
12:36 hakzsam: sure
12:36 imirkin: and correspond to the ->set_shader_image() thing
12:36 hakzsam: that makes sense
12:37 imirkin: while BUFFER[] will correspond to ->set_shader_buffer()
12:37 imirkin: mareko hated the idea of a shared RESOURCE thing for them
12:37 imirkin: and it's also not really how the hw or GL works
12:37 hakzsam: I agree that this RES thing is really weird
12:37 hakzsam: it's both used for global buffers and for "images"
12:38 imirkin: for GL, IMAGE declarations will have a format
12:38 imirkin: while for CL, there will have to be a way to explain to the shader that the format is expected to come via some sideband channel
12:41 hakzsam: note that CL images are mostly supported by clover but I don't know the specifics
12:41 imirkin: yeah, i was talking about it with EdB earlier
12:41 imirkin: it's *most* likely that clover will need updates too
12:41 hakzsam: yup
12:42 imirkin: but i haven't really thought too much about it
12:44 hakzsam: imirkin, except that, I don't think your series breaks anything else related to compute
12:44 imirkin: well, my nvc0 changes do :)
12:44 imirkin: i leave the old code in place, but basically neuter it
12:44 hakzsam: which ones?
12:45 imirkin: well everything related to resources is commented out
12:45 imirkin: https://github.com/imirkin/mesa/commit/b28beae57a86845a3793e1ae568b34d88200b1c4
12:45 imirkin: and in there i basically just do if (buffer) { do things that work; return; }
12:45 imirkin: and leave the non-buffer case with the old code
12:49 hakzsam: imirkin, so yes, you didn't break anything else related to (core) compute for nvc0 :)
12:49 hakzsam: you only did break the tgsi interface
12:49 hakzsam: for compute
12:49 imirkin: right
12:49 imirkin: kind of an important bit of compute though :)
12:49 hakzsam: but except two people (hans and me), I don't think anyone else try to compile compute.c :-)
12:50 imirkin: EdB was playing with it too
12:50 imirkin: and i do feel bad about breaking it :)
12:50 imirkin: but not bad enough to rewrite it
12:50 hakzsam: really?
12:50 hakzsam: strong argument for updating it, np? :)
12:50 hakzsam: *no
12:50 imirkin: it was relying on interfaces that no one was using
12:51 imirkin: we're redoing those interfaces
12:51 imirkin: (not only no one was using, but also no one was implementing, except nouveau)
12:51 hakzsam: is that possible to introduce BUFFER and IMAGE without removing RES for now, right?
12:52 imirkin: nothing uses resource.
12:52 imirkin: it would confuse the nouveau code even more than it already is.
12:53 hakzsam: that's true (for the nouveau code complexity)
12:54 hakzsam: well, go ahead and I'll update compute.c myself once the interface will be more suitable
12:54 imirkin: ok
12:54 hakzsam: (ie. when BUFFER and IMAGE will be implemented)
12:55 imirkin: right
12:55 hakzsam: imirkin, please, just add a note about that in your commit message
12:55 imirkin: will do
12:55 hakzsam: thanks
12:56 ennui: Could anyone point me to instructions for raising my GF110's performance mode? I have a VG248QE (144Hz) monitor and am experimenting with increasing refresh rate beyond 60Hz while on nouveau in wayland/weston and nouveaufb. I'm running kernel 4.3.3.
12:57 imirkin: ennui: can't be done for now, sorry
12:57 imirkin: ennui: however you should be able to use 144Hz just fine...
12:57 ennui: `fraid of that. Thanks imirkin.
12:57 imirkin: ennui: what's the issue?
12:58 ennui: Well, I can get higher refresh rates out of the card and onto the monitor. I can see from the monitor's onscreen display that the signal is 144Hz and 120Hz as expected.
12:58 imirkin: ah but memory doesn't keep up so it's all flickery?
12:58 ennui: However, the image isn't usable -- weston shows up as mostly red at 144Hz/120Hz, for example.
12:58 imirkin: iirc red = scanout too slow
12:59 imirkin: so yeah, you need to clock your memory up. sorry, that's not possible on fermi right now with nouveau
12:59 ennui: All of the images presented on the monitor are more or less static.
12:59 ennui: nouveaufb shows up as mostly lines of grey, followed by some more lines of . . . different gray.
13:00 imirkin: heh
13:00 hakzsam: imirkin, hey, you replied too :)
13:00 ennui: OK, thought that was probably the case from what was posted on the nouveau wiki -- was hoping there were some more kernel parameters to tweak. :)
13:01 hakzsam: imirkin, time to work on arb_compute_shader now
13:02 ennui: Thanks for your help, though. Will keep watching to see if Fermi gets more support here.
13:02 imirkin: someone has been making very small progress on fermi... however nothing closer to feature-complete yet
13:06 ennui: Is it Kepler that has the best reclocking support at the moment?
13:09 imirkin: ennui: kepler and the late-model tesla's (i.e. GT21x)
13:22 phomes: I have a 8800 GT desktop card (G92)and writing to pstate fails with "Function not implemented". On kernel 4.4 rc6. I am testing a few cards and this is the first one to show that.
13:22 phomes: reading it shows only one option though:
13:22 phomes: 0f: core 670 MHz shader 1675 MHz memory 975 MHz
13:23 phomes: AC: core 399 MHz shader 810 MHz memory 499 MHz
13:23 imirkin: phomes: and the AC, which is current
13:23 imirkin: phomes: that's how most older GPUs are... they come up at some slower boot clock, but have only one (higher) perf level available
13:24 phomes: ok - so the write error is expected when I write 0f to it?
13:26 imirkin: phomes: pre-G94 gpu's aren't supported by the code right now... if you feel brave you could hack it to just use the current logic on your G92
13:27 imirkin: phomes: but it's quite likely to just hang your gpu
13:28 imirkin: phomes: if you feel so inclined, just change this line in your kernel: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/clk/g84.c#n47
13:28 imirkin: (0x92 would expose it for your GPU instead of 0x94)
13:28 imirkin: [btw, i'm assuming this is with GDDR3 vram... if it's DDR2 it'll definitely not work]
13:41 phomes: it is DDR3. I don't mind compiling a kernel with that change if you think it is worthwhile for nouveau. The card is just one I have temporarily borrowed to verify working pstate with.
13:42 imirkin: phomes: afaik it's never worked for anyone with a G92. but you could be the first :)
13:42 imirkin: (i think only like 1 other person tried, so it's not exactly a large sample size)
13:43 RSpliet: even on G94+ the sample size is very limited tbh
13:43 imirkin: but much larger... like 2 :)
13:44 RSpliet: if we include NVA0, maybe even 4 or 5
13:45 phomes_: I just tested a G94 (quadro FX 1800) earlier tonight. No problems there
13:53 karolherbst: imirkin: I don't get the trace replayed :/
13:53 imirkin: karolherbst: dolphin-emu-nogui fortune_street.dff
13:54 karolherbst: yeah I mean I can get dolphin to play it, but with intel it crashes and with the blob it does display nothing
13:54 karolherbst: if it plays at all
13:54 karolherbst: maybe my dolphin version is too new
13:54 karolherbst: 4.0-8542 is a bit old
13:55 karolherbst: or is it the newest?
13:55 karolherbst: mhhh
13:55 karolherbst: something is odd
13:55 imirkin: uhhhh
14:01 karolherbst: imirkin: sensors output: "GPU core: +0.88 V"
14:01 imirkin: ok
14:01 psaisanas1: Imirkin: regarding NV47 on ppc64, mesa is working now! Thanks for the patches in mesa 11.0.3!
14:01 karolherbst: the hwmon documentations is pretty strict about that. the name says what it is already
14:01 karolherbst: and labels shouldn't be used except you really don't know what is meant directly
14:02 imirkin: ben also told me that "in0" is a synonym for voltage... i have no clue why, but as long as everyone's in agreement, that's fine by me
14:02 imirkin: psaisanas1: awesome!
14:02 karolherbst: imirkin: hwmon documentations :D
14:02 imirkin: psaisanas1: do note that it's still not *quite* right, but should be a ton better than before.
14:02 karolherbst: imirkin: https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface
14:02 imirkin: karolherbst: ok, but it's not like anyone will read that
14:02 imirkin: karolherbst: or at least... it's not like *i* will read that ;)
14:02 karolherbst: it is rather nice to read though
14:03 karolherbst: imirkin: yeah, that's why sensors puts a V there so you know what is meant by that ;)
14:03 karolherbst: we could leave it out though, but I thought maybe we know in the future how to get the memory voltage
14:04 psaisanas1: imirkin: I know, still have odd colours with egl (i.e. when running weston compositor). But hey, progress is progress!
14:04 imirkin: psaisanas1: my basic goal was glxgears in X :)
14:05 imirkin: karolherbst: "return-ENOMEM" is usually written as "return -ENOMEM"
14:05 karolherbst: ohhhh :O
14:06 imirkin: skeggsb already fixed it
14:07 karolherbst: k
14:07 psaisanas1: imirkin: yep, I'm getting around 380fps with glxgears. I guess this is roughly about right!
14:07 imirkin: psaisanas1: maybe, dunno. glxgears isn't great at measuring perf... you could try glmark2
14:07 imirkin: if there's a ppc64 build
14:08 psaisanas1: imirkin: tried compiling glmark2 with x11-gl but segfaults :(
14:08 imirkin: oh, it might require more GL than is available
14:08 karolherbst: imirkin: no idea why, but I get unknown opcode errors
14:09 imirkin: karolherbst: like in dmesg? or on the cpu?
14:09 karolherbst: from dolphin
14:09 imirkin: karolherbst: i mean... SIGILL or INVALID_OPCODE reported by nouveau?
14:09 imirkin: oh... weird.
14:09 karolherbst: from dolphin ;)
14:09 karolherbst: :D
14:09 imirkin: try redownloading?
14:09 imirkin: and/or updating dolphin
14:10 karolherbst: well I am on current master
14:10 imirkin: weird. worksforme =/
14:10 karolherbst: maybe I need to enable llvm support?
14:11 imirkin: unlikely
14:15 karolherbst: hehe it crashes now in libEGL
14:16 karolherbst: well I might want to disable egl thenä
14:23 karolherbst: imirkin: all looks like the right version
14:23 karolherbst: intel, nouveau, nvidia
14:24 imirkin: karolherbst: ok thanks for confirming!
14:24 karolherbst: imirkin: do you think increasing the video buffer would have any noticeable impact?
14:24 imirkin: karolherbst: on what?
14:24 karolherbst: no idea, that's why I am asking
14:25 imirkin: i think it's either big enough or not
14:25 imirkin: i pushed a change that sizes it "dynamically" according to the video size
14:25 karolherbst: checking it out
14:26 imirkin: and also the bitplane_bo -> client change
14:26 karolherbst: yeah saw it
14:26 karolherbst: should I play around with that until it messes up again? :D
14:26 imirkin: heh
14:26 imirkin: if you like
14:26 karolherbst: sould be easy :)
14:28 karolherbst: ohh wait
14:28 karolherbst: okay I think this could work
14:28 karolherbst: even if the size is twice as big as really needed
14:28 karolherbst: because the old value was already fine enough for 3k videos ;)
14:28 karolherbst: so yeah
14:29 karolherbst: will try to mess it up anyway
14:41 karolherbst: imirkin: okay, 330% cpu load with the file I created now (while playing on the cpu)
14:41 imirkin: congrats?
14:54 karolherbst: imirkin: do you know if vdpau can handly yuv444 videos?
14:54 imirkin: iirc i tried it once and my gpu insta-hung
14:54 imirkin: i did not investigate further ;)
14:54 imirkin: errr, it was yuv422
14:54 karolherbst: ohh okay
14:54 karolherbst: with yuv444 I just get green stuff
14:54 imirkin: yummy delicious green stuff
14:55 imirkin: make an mmt trace of the blob doing it
14:55 imirkin: perhaps i'll take a look
14:55 karolherbst: yuv422 also green
14:57 imirkin: make an mmt trace of nvidia doing it
14:57 karolherbst: k
14:59 imirkin: maybe that'll motivate me to teach demmt about all the video bs
15:00 karolherbst: imirkin: well I get garbage with the blob :D
15:01 imirkin: ah... probably don't need a mmt trace of that
15:02 imirkin: we know how to generate garbage all by ourselves
15:03 karolherbst: well it is less garbage than nouveau prints out though
15:03 karolherbst: :D
15:03 karolherbst: you can actually recognize some bits of the video
15:03 karolherbst: but it is all greenish with lines and stuff
15:04 karolherbst: maybe I find something official what the card supports at all
15:05 karolherbst: imirkin: max resolution is "4032 × 4080"
15:05 imirkin: for kepler yea
15:06 karolherbst: and those VP5 fermis
15:06 imirkin: ah yes. GF117/GF119
15:07 imirkin: karolherbst: feel free to send a patch.
15:07 karolherbst: for what? :D
15:07 karolherbst: for the fermi ones or to support 4032x4080?
15:08 imirkin: i'm sure we claim the max to be 4096x4096
15:08 imirkin: case PIPE_VIDEO_CAP_MAX_HEIGHT:
15:08 imirkin: return vp5 ? 4096 : 2048;
15:09 karolherbst: right
15:09 karolherbst: will try that out :)
15:13 karolherbst: mhh I see only black
15:13 imirkin: open your eyes?
15:15 karolherbst: 4000x4000 works
15:16 karolherbst: so 4096x4096 max seems wrong somehow
15:16 imirkin: it def is
15:20 n7025: i always asked me: When some GPU Card tells "Supporting DP 1.0" at the time as just DP 1.0 was existing, could this card get DP 1.1 ... support by adding DP 1.1 support to the VBIOS/Driver?
15:21 imirkin: it's usually a matter of electrical-level support, so no
15:23 n7025: its really electrical-level? Because for example EDID version 1.0 can be just rewritten to version 1.3 and reflashed again to the memory. Then its a correct edid 1.3. Also some SATA1 thinkpads could get SATA2 just by adding support for SATA2 to the BIOS
15:26 imirkin: EDID is a piece of data
15:26 imirkin: DP is a connector
15:26 n7025: with same wiring to version 2.0 since version 1.0
15:27 imirkin: uhhhh
15:27 n7025: its just how they talk over this wires. am i missing something?
15:27 imirkin: the signal requirements are very different
15:27 imirkin: even if the wires are the same
15:29 n7025: and the GPU chipsets are not flexible enough to talk with the required signal requirements?
15:30 imirkin: usually the wiring itself will be non-compliant
15:30 imirkin: for the higher frequences
15:32 n7025: it would be nice if this can be tested somehow. Maybe its not enough for the standard but enough for a 1m long cable
15:33 n7025: or even 50cm long cable
15:34 n7025: and for example the difference between DP 1.2 and 1.2a is just the FreeSync functionality. That must be just a vbios thing.
15:34 imirkin: depends on the DP encoder
15:36 mjg59: If the encoder doesn't have the bandwidth to do 1.2, software isn't going to help you
15:37 mjg59: Outside that, it's probably still going to be influenced by the functionality that the encoder offers
15:37 n7025: mjg59: but maybe the encoder have the bandwidth to do 2/3 of the speed of DP1.2 . So this would be already enough to run the required resolution
15:38 n7025: mjg59: where does those encoders sit? outside the gpu chipset?
15:38 imirkin: n7025: these things aren't designed randomly... if an encoder is designed for DP 1.1, it will meet those requirements and not any more, because more would mean more expensive.
15:38 imirkin: for absolutely no benefit to the manufacturer
15:39 n7025: imirkin: yes, i know. but its a common thing of the manufacturer to just reduce the capabilities by software and use one and the same chipset in different situations.
15:40 n7025: here is a nice example of a VBIOS thing: https://www.techpowerup.com/forums/threads/question-on-displayport-1-2-1-2a-and-adaptive-sync.200946/#post-3109759
15:40 n7025: AMD changed the firmware between the 7970 and R9 280X transition, allowing 3 DVI monitors in Eyefinity on the 280X but only two on the 7970. All it needed was a firmware update, but when I emailed AMD about it they said they had no plans to offer support for the older products like mine even if it was the same hardware.
15:41 mjg59: In that case they're creating market segmentation
15:42 n7025: mjg59: thats why i am interested to understand the basics if it were possible to check at what DP-frequency the chipset really messes up the signal
15:43 mjg59: I'd be surprised if they created segmentation over displayport version
15:43 n7025: for example adding freesync support to devices with DP 1.0 or 1.1 would be interesting.
22:24 uriah: imirkin: seems like the performance i was hoping to gain with the new kernel / driver i updated to is there
22:24 imirkin: uriah: awesome
22:24 imirkin: uriah: although i apologize, but i've entirely forgotten your situation :)
22:24 uriah: i mean, i was using a 3.14 kernel, so it was pretty obvious that there would be *some* performance gain
22:24 uriah: imirkin: i was wondering what the status of nv30 was ;)
22:24 imirkin: ahh
22:25 imirkin: i'm actually surprised that *just* a kernel update would have made too much difference as far as nv30 accel was concerned
22:25 imirkin: but if you also updated mesa, then i can see there being some improvements
22:25 uriah: well there was very slow performance even when scrolling up/down a terminal emulator in X
22:25 uriah: yeah
22:26 uriah: i also updated everything else lol
22:26 imirkin: ah ok, yeah. good idea :)
22:26 uriah: :>