01:28 mlankhorst: skills is easy, just use more time :P
03:33 mlankhorst: tagr/gnurou: Do you know if lauri peltonen is on irc?
05:35 nicoo: Hi. I have a GT218M (so a NVA8 chip, Tesla family), on (X)Ubuntu Utopic Unicorn amd64, and support for it is quite flaky: the presence of an external screen on the DVI port isn't always detected (according to xrandr), and trying to suspend/resume (or sometimes trying to enable the external screen) produce some strange failure where I get moving colored patterns on the display, instead of my DE
05:36 pmoreau: nicoo: Could you please paste somewhere the output of dmesg? And on which kernel version are you?
05:37 nicoo: 3.16.0-31-generic
05:39 nicoo: http://dpaste.com/055DTQY
05:40 pmoreau: Thanks
05:42 pmoreau: Is it one when you get weird colored patterns on the screen?
05:43 nicoo: This is the machine (and kernel + whole userspace) I get the issue with
05:43 nicoo: http://dpaste.com/25JDHEJ if you need the lspci output
05:44 pmoreau: Ok, but when you produced the dmesg, were you experiencing any colored patterns?
05:45 pmoreau: (SOrry, gtg. If nobody else can help now, please open a bug report at bugs.freedesktop.org)
05:46 nicoo: Ok
05:46 nicoo: For the record, if I try to suspend/resume, I'm pretty sure I will hit the issue again
05:50 nicoo: Also, I forgot to say that sometimes, nothing is displayed on the laptop's internal screen (or just a 1px-thin horizontal line) after the BIOS graphics & messages, and it requires rebooting (but the system is otherwise functional, plugging an external display works)
05:51 nicoo: Had none of those issues (but some others ...) with the proprietary drivers
06:03 pmoreau: (Back again)
06:04 pmoreau: You could try booting with nouveau.config=NvMSI=0 on the kernel command line
06:10 pmoreau: nicoo: You could also try 3.19 and see if someone already fixed it.
06:22 gansteed: archlinux with nouveau driver installed, cann't suspend when I close the lid(only dual monitors behave like this).
06:24 nicoo: pmoreau: Will check
06:24 pmoreau: gansteed: Which card do you have?
06:24 gansteed: GT650M
06:24 pmoreau: And any errors in dmesg?
06:25 gansteed: no
06:26 pmoreau: Could you please paste it somewhere? (Not that I don't trust you, I'd like to check some other things as well)
06:26 gansteed: pmoreau, wait a minute :)
06:27 gansteed: pmoreau, should I filter other messages?
06:28 pmoreau: No need for filtering, just a plain dmesg
06:28 pmoreau: Except if it contains some secrets you don't want to share ;)
06:28 gansteed: ok
06:30 gansteed: pmoreau, http://lpaste.net/121537
06:31 pmoreau: Thanks!
06:31 gansteed: :)
06:32 pmoreau: I can't even see an APCI_CLOSE_LID or whatever the ACPI signal is called
06:33 pmoreau: Did you try closing the lid before getting the dmesg?
06:33 gansteed: pmoreau, yes, I've do this 3 times
06:33 gansteed: is it the reason of systemd?
06:33 pmoreau: :/
06:34 gansteed: one more thing, I have not install acpid
06:34 pmoreau: I don't think so, it works on my laptop which also have systemd (also using Arch)
06:35 gansteed: but it works when I use my laptop's screen only
06:35 pmoreau: Hum...
06:36 pmoreau: Could you get a dmesg output when closing the lid with only your laptop screen?
06:37 gansteed: ok
06:38 gansteed: just wait
06:42 imirkin: the lid close event has nothing to do with nouveau
06:42 pmoreau: Right, but it could have been Nouveau failing to suspend
06:43 gansteed: pmoreau, here it is:http://lpaste.net/121538
06:43 pmoreau: Let's see
06:44 imirkin: looks like it suspends and then immediately wakes up
06:44 gansteed: it's when I just unplug the VGA , and then close the lid
06:45 pmoreau: So it works with only the laptop screen, but there is no suspend signal when having an external screen
06:45 gansteed: http://lpaste.net/121539
06:45 gansteed: this time I logged out, and log in, then close the lid
06:46 gansteed: without VGA
06:46 gansteed: imirkin, yes, you're right
06:47 gansteed: the second time works well
06:53 pmoreau: You can see on the first paste that there is no filesystem synchronisation synchronisation, which is done before suspending (see around line 1095 in the second paste). And Nouveau is never asked to suspend either.
07:02 gansteed: so how can I solve this problem?
07:03 gansteed: let me try nvidia driver :) so I'll know it is the problem of nouveau or something else.
07:03 pmoreau: Not sure... Maybe ask the ACPI guys?
07:11 gansteed: it's the same :(
10:43 hakzsam: imirkin, do you still need glxinfo output for nva3-nvaf ?
10:43 imirkin_: hakzsam: yes
10:43 hakzsam: okay
10:44 imirkin_: (excluding nvaa/nvac)
10:44 hakzsam: it's a nva8
10:44 imirkin_: awesome
10:44 hakzsam: :)
10:45 hakzsam: let me build mesa 10.5-rc2 on my own REator ;)
10:45 imirkin_: hakzsam: hehe awesome. the "real" one is having some issues, if you'd be up for "sharing" it, i'm all for! :)
10:48 hakzsam: I didn't set up wtrpm yet, so I can't really give you an access
10:50 imirkin_: ah ok
10:50 imirkin_: well hopefully mupuf will be able to figure out wtf is wrong with his
10:50 hakzsam: yes
10:50 hakzsam: and he also has a nva8 IIRC
10:51 imirkin_: well, i wanted to debug a nv4x thing on his box
10:54 hakzsam: it takes time to build mesa with a core2duo...
10:55 imirkin_: thankfully you don't have have to watch it patiently as it builds
11:11 hakzsam: imirkin_, http://paste.awesom.eu/zqhk
11:12 hakzsam: I added --enable-texture-float this time
11:12 imirkin_: cool thanks :)
13:56 zolo: Hi all, I have probably dumb question, but i need ask. If I want start learn how to write drivers, comunicate with gpu, which brand is best? Amd/Nvidia/Intel? And whis of some new gpu architectures ist most well documented and good for start? Thanks for responses.
13:58 tobijk: zolo: amd and intel are well documented, nvidia isn't
13:59 imirkin_: intel probably has the best docs... amd's are decent too
13:59 zolo: So good will be start with cgn? Or something earlier?
13:59 zolo: Or that intel?
13:59 imirkin_: i think it'd be good to figure out what it is you want to do
13:59 airlied: though the docs sort presuppose you have some understanding of gpus
13:59 imirkin_: gcn, in reference to the ISA, is a small and largely irrelevant bit of the gpu
14:00 imirkin_: [it's important to stuff the right opcodes through, but unless you're interested in compilers, it's largely unrelated to overall gpu operation]
14:01 imirkin_: yeah, those docs are pretty hard to read
14:01 imirkin_: like i said, step 1 for you will be narrowing focus
14:02 buhman: how would you magic 'some understanding of gpus'?
14:02 zolo: I simply want begin with graphigs development, want how it all works and try implelent some simple 2d driver... I want focus on this in my life, but i need help how to start
14:03 airlied: there is no such thing as a simple 2d driver anymore
14:04 airlied: even a simple modesetting driver is quite large
14:05 zolo: I´m 17 year old student that only beginning with things like this... I trying now to do some simple os, to know how all this works in internals, and graphigs driver is something too complex - i like complex things :D
14:05 airlied: even big OSes can't write graphics drivers
14:06 RSpliet: airlied: is Ben amongst the living right now? or still on holiday? :D
14:06 zolo: If i will take 3 years and lot of spare time, no problem... but i need know how is best to start
14:06 airlied: and while I understand the wanting to understand all of the things, yuou really need to start smaller with gpus and focus on one thing
14:06 airlied: RSpliet: I saw him yesterday!
14:07 zolo: i want focus on gpus
14:07 RSpliet: airlied: haha, that's good to hear :-)
14:07 RSpliet: zolo: a GPU is a big thing... it's like, 2x2cm of transistors
14:08 RSpliet: that's first divided into "display" and "rendering", with lots of shared functionality like a memory hierarchy, decompression logic etc. etc. Take it one step at a time ;-)
14:10 imirkin_: zolo: best to take something that works and modify. creating from scratch is tremendously difficult
14:12 zolo: but i still dont know where to begin...
14:12 imirkin_: easiest to take the hardware that you have
14:12 imirkin_: and play with it
14:12 imirkin_: if you're really interested in gpu's... what gpu do you have on-hand?
14:35 zolo: now intel hd :D but i want buy some new, probably some amd cgn
14:35 drago01: its gcn not cgn btw
14:36 zolo: dont exist some old simpler architecture well documented?
14:36 zolo: buying some old pc is not problem
14:38 RSpliet: zolo: why wouldn't you just learn a new one... one step at a time?
14:38 zolo: one step at a time?
14:39 RSpliet: pick a topic, say display... narrow it down to something basic (like VGA), read about it, think of 5 "problems" in the area of displaying an image over VGA, work out how they work ;-)
14:40 RSpliet: it's easier to read the code there's out in the open source community if you understand the problems it's trying to solve
14:41 zolo: nobode released some book or something similar?
14:41 zolo: *nobody
14:42 RSpliet: next... think of the difference between say VGA and DVI, and work out of that changes anything... or continue on understanding the "image" part in "displaying an image over VGA"
14:43 RSpliet: the point is, approach the device as a thing that solves a hell of a lot of problems. First understand the problem, the figure out the solution (which is often times very straightforward once you get the problem it's trying to solve)
14:44 imirkin_: zolo: intel hw is fairly well documented and all the code is open...
14:44 zolo: but some old gpus were a lot simpler, and i need try it on real hardware, not?
14:45 RSpliet: no, not necessarily
14:45 zolo: so isnt some ooold gpu architecture that is simple and well documented?
14:45 RSpliet: I'd say that the NVIDIA FX is more complex than the newer NVIDIA GeForce 8xxx
14:46 imirkin_: meh... it can do fewer things, and is simpler in that way
14:46 imirkin_: writing a vec4 compiler is more painful than a scalar one though
14:46 RSpliet: imirkin_: and writing 2 compilers is more painful than writing one :p
14:47 imirkin_: is vp isa really that different from fp?
14:47 zolo: where you learned all you know?
14:47 RSpliet: on the opcode level, definitely
14:47 imirkin_: i guess i never looked at the details :)
14:47 imirkin_: zolo: by taking something that worked and then modifying it
14:47 imirkin_: RSpliet: yeah, the opcodes are all different, but they have basically the same caps...
14:48 imirkin_: zolo: for example, take a piece of hardware, build mesa opengl driver, run piglit (test suite) against it, try to understand the failures and fix them
14:48 RSpliet: imirkin_: not entirely sure about that. I recall branching to be quite different
14:48 imirkin_: RSpliet: FX didn't have branching
14:49 RSpliet: NV4x does... a little
14:49 imirkin_: yeah, but that's not FX :)
14:49 RSpliet: you're right, it's the successor... the ISA is largely unchanged though :-)
14:49 RSpliet: anyway, we're diverging
14:49 imirkin_: yeah, they just added branching, more varyings, probably some other stuff
14:49 zolo: ok... so best will be begin with intel, read all documents, read source that works, but some things in that documets i dont understand and i dont know where learn it
14:50 imirkin_: diverging is fun
14:50 imirkin_: zolo: you won't be able to read (well... understand) the docs
14:50 RSpliet: zolo: my advice; pick a particular problem you want to understand. That'll help focus
14:50 imirkin_: zolo: instead take some function and try to understand what the code supporting that function does
14:50 RSpliet: and "displaying graphics" is not the kind of problem I'm talking about :D
14:50 imirkin_: you can use the docs to help you understand what the code does
14:51 zolo: ok what part is good to start?
14:52 RSpliet: that depends on you
14:52 RSpliet: I made the horrible mistake of starting off with the clock distribution network. It's interesting, but I've wasted many hours on it (and learned a lot in the process... :-P)
14:52 zolo: and nothing more than that docs dont exist? Some genersl gpu architecture docs, or similar?
14:52 RSpliet: zolo: you can learn OpenGL
14:52 imirkin_: RSpliet: i dunno if 'hours' are the best units to describe it
14:53 RSpliet: imirkin_: "hairs"
14:53 imirkin_: many hairs have grayed in the process? :)
14:53 RSpliet: or went missing
14:54 zolo: something docs that says: hn you move window, gpu thakes that buffer... and what that buffer is... basic stuff like this dont exist in docs... prom code it is hard to understand...
14:55 imirkin_: zolo: it's definitely a difficult field to break into... a lot to learn up front before anything really makes sense
14:55 zolo: *some docs that says: when...
14:55 RSpliet: zolo: aha, but you did identify an interesting problem ;-)
14:55 imirkin_: a surprisingly complex one considering how simple it should be :)
14:56 zolo: what?
14:56 RSpliet: "moving a window"
14:56 RSpliet: how would you do it?
14:56 RSpliet: think about it ;-)
14:57 imirkin_: anyways... the approach i'd suggest is to do a piglit run and try to figure out what's failing and why
14:58 imirkin_: every time i analyze failures i learn something new
14:58 RSpliet: imirkin: yes, but now we can toss terms around (the ones you probably know a lot better than I do) like compositing, double buffering, buffer formats, damage... :p
14:59 imirkin_: meh, i still haven't a clue how GL sends images to the screen... all that winsys stuff... i've totally ignored it. seems to work, and is largely uninteresting to me.
15:06 zolo: but thinks like what is buffer, and similar... must be some documentation for it
15:06 imirkin_: things like "buffer" can mean a lot of different things in a lot of different contexts
15:07 imirkin_: diff people learn differently i suppose, but i'm best when exploring the details of a very concrete situation
15:13 airlied: you could I suppose read some of the half written book
15:13 airlied: http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf
15:16 zolo: airlied really thanks :) thats exactly what I wanted
15:16 airlied: its not complete though, a fair few gaps in it
15:18 zolo: you writing it?
15:19 airlied: no it was marcheu who started it
15:19 mupuf: airlied: he still is responsible for 98% of it
15:19 zolo: but in state what is now is really useful thanks
15:19 mupuf: I helped a tiny little bit ... unless it was on the other guide
15:21 zolo: and that chapters that are written... they are already made, or you will add some things to them?
15:21 zolo: or you will only add chapters?
15:24 marcheu: zolo: if you send chapters I will add chapters :)
15:25 marcheu: but it's a lot of work, between putting things together, phrasing everything properly, doing nice typography, pretty images etc.
15:25 marcheu: so it moves slowly :(
15:27 zolo: if it will be actualised that link will be actual too?
15:28 marcheu: the link with the pdf is updated by hand, so it's hit and miss. btw the source is at http://cgit.freedesktop.org/~marcheu/lgd/
15:29 zolo: yes i know it is a lot of work write book
15:29 zolo: but it will be so useful, stay motivated :D
16:47 zolo: lovest level :D http://neil.franklin.ch/Projects/SoftVGA/
18:47 Superymk: Hi, I am looking into which function is responsible to show framebuffer on screen (for nv50, in specific, and not for VGA mode). I found <nv50_crtc_set_image> function, is that the correct one? I don't see any PGRAPH/PDISPLAY register to be programmed then, but I see the cursor is programmed in a similar way (instead of programming PGRAPH/PDISPLAY)
18:48 gnurou: mlankhorst: I don't think he is - better send him an email directly
18:48 imirkin: Superymk: i think it's just done with evo
18:49 Superymk: imirkin: Yes, I see there is a lot of evo_mthd and evo_data inside that function
18:50 imirkin: Superymk: evo is a fifo-type way of sending commands to the display engine
18:50 Superymk: then could I read the setting out? via registers or so
18:51 imirkin: yeah probably
18:51 imirkin: check g80_display.xml in rnndb
18:54 Superymk: I see. Thanks a lot! BTW, in my understanding of this function, the VRAM physical address is passed in as bo.offset, right?
18:54 imirkin: bo->offset is the gpuvm address
18:55 imirkin: the physical address is annoying to get
18:55 skeggsb: nah, it's a physical address in this case
18:55 imirkin: then it's not a nouveau_bo bo
18:56 Superymk: nvfb->nvbo->bo.offset
18:56 skeggsb: well, nouveau_bo doesn't contain a virtual address anyway, there are multiple of those per-bo
18:56 skeggsb: bo.offset is a physical address for pinned buffers
18:56 imirkin: hrmph, it's been too long since i've looked at the kernel code
18:57 imirkin: certainly in *userspace* it's the gpuvm address :)
18:57 skeggsb: yes :)
18:57 Superymk: I see, thanks imirkin and skeggsb !!
18:58 imirkin: got *one* right
23:40 gnurou: skeggsb: woohoo, thanks for the merge!
23:42 skeggsb: gnurou: sorry for the delay, i've been away a couple weeks
23:44 gnurou: skeggsb: no, that's great - now I just need to propagate this flag into libdrm and Mesa
23:45 gnurou: I guess the interface for libdrm is not automatically updated, is it?
23:46 mupuf: gnurou: nope, you need to update it yourself
23:46 mupuf: skeggsb: welcome back!
23:47 gnurou: mupuf: thanks, will do at once
23:48 gnurou: with that we will finally have all the user-space changes usptream for Tegra support
23:55 mupuf: gnurou: that means that the kernel space is also ready?
23:55 mupuf: In any case, congrats!
23:57 gnurou: argh, there is still that damn firmware
23:58 gnurou: mupuf: firmware apart, it is just a matter of enabling the GPU node in the device tree
23:59 gnurou: oh, and I forgot the issue with render-nodes... Most user-space apps (e.g. Weston) cannot handle this and still require a patch
23:59 mupuf: which firmware?
23:59 gnurou: gk20a's
23:59 mupuf: ah ah, sure! I meant which engine :D