11:44mareko: oh man, a threaded gallium wrapper isn't worth it. even a lockless queue (atomics and sched_yield) is 4% slower than no wrapper, and a locking queue is 33% slower
11:45mareko: a lockless queue might be a good idea for glthread though
12:07xexaxo1: mareko: I take it by "threaded wrapper" you're not talking about tstellar's gallium/drivers/threadsafe ?
12:51mannerov: mareko: that's quite surprising
12:52mannerov: have you tried a system like gallium nine ? We don't use atomics much (but we assume one producer)
12:53mannerov: we don't flush often too. We don't use sched_yield
12:58mareko: mannerov: how does your queue work then?
12:58mannerov: we use several buffers
12:58mannerov: we use locks to pick the buffer
12:59mannerov: the producer then fills the buffer until it's full of commands
12:59mannerov: then it release it and picks a new one
12:59mannerov: the consumer only works when it has at least one buffer of commands ready
13:00mareko: mannerov: how does the queue of buffers work?
13:00mannerov: our code for that part is in nine_queue.c
13:01mannerov: the nine_csmt_helpers is for writing functions that convert the call into commands
13:02mannerov: we found out that using big enough buffers is important. You avoid locks, and the consumer is only awaken when it has significant amount of work, and thus you avoid thread switching.
14:31robertfoss: stark3y: did you have a chat with tsa about intel-ci testing?
14:50stark3y: robertfoss: yeah, thanks. He's got the series and I gave your test list
14:50robertfoss: stark3y: excellent
14:50robertfoss: stark3y: whenever you're happy with the results, I think we can push the series
14:51stark3y: Ok I will update that thread when I know
14:51stark3y: (v2 thread)
17:10xes: patrik: ping
17:19xes: hi patrik. I'm pinging you about the gma550_gfx. I can see you are involved into a bug submission: https://bugs.freedesktop.org/show_bug.cgi?id=78562. While it is possible to live with the poor performance of that card, that screen flickering can really destroy the eyes. Have you any idea, any possible solution or trick to solve or mitigate this problem?
18:25Hi-Angel: Should I include the line "α files changed, β insertions(+), γ deletions(-)" to a patch? "git diff" didn't seem to have it, I'm wondering if it's needed
18:26bnieuwenhuizen: try git format-patch
18:27bnieuwenhuizen: It'll still not have it, but you generally don't need it
18:27bnieuwenhuizen: you can do e.g. git format-patch -10 --cover to take the last 10 commits and add an introduction file, and the introduction file contains the line counts
18:28bnieuwenhuizen: oh git format-patch also contains the counts, nvm
18:28Hi-Angel: Okay, thank you
18:55Hi-Angel: Hmm odd, when I look the patch I sent through lists.freedesktop.org/archives it have wrapped lines. But in the mail I've got from the list they're normal. I just didn't see alike behavior in other people's patches, so it worries me a bit.
18:55imirkin: Hi-Angel: your patch is fine
18:56Hi-Angel: Okay, thank you
18:56imirkin: although looks like some oddness such as
18:56imirkin: - u_upload_data(device->constbuf_uploader,
18:56imirkin: + u_upload_data(device->context.pipe->const_uploader,
18:56imirkin: but i don't think that's the mailer's fault... more like you formatted it weird
19:02Hi-Angel: Hmm, indeed it looks like this even in the sent mail, though the patch file from which I copied everything didn't have the problem. Interesting… I'll resend it.
19:03bnieuwenhuizen: you can also send with git send-email
19:05Hi-Angel: Hehe, I sent the mail to myself, and the problem reproduced. I probably have to look at disabling formatting in thunderbird.
19:09imirkin: Hi-Angel: yeah, mail clients tend to mess things up. you really want to use git send-email or something else which just sends your email without trying to be clever
20:12thohel: someone mind having a look at some i965 shader assembly dumps? I've been meaning to send out a revised version of the quad-hashing hash table, but have been stomped by an unexpected functional change
20:13thohel: it appears that I get a change in cycle count when running shader-db on some dota2 shaders. I'm not sure if this could be explained by register allocation though, and that it is "normal".