00:05skeggsb: gnurou: on earlier GPUs, it used to complain if you messed up linear vs tiled
00:06skeggsb: if you wanted to use kind 0, you needed to explicitly say you were doing a linear operation
00:06gnurou: mm, strange that it didn't complain then indeed
00:07gnurou: it just happily took everything I gave it and outputed solid black
00:07skeggsb: that was nice of it :P
00:08gnurou: no it wasn't :P
00:14gnurou: anyway, patch sent - now back to secure boot!
03:48karolherbst: nice, found my bugzilla credentials again
03:56karolherbst: so if somebody wants to look over this I would appreciate it: https://github.com/karolherbst/nouveau/commit/18c509feadda1a7fe166563a4cc883cbc2e155b1
05:13karolherbst: imirkin, mupuf: fyi, my card is now at 25% compared to blob with bumblebee, its at 12% without pstate
05:14karolherbst: tested in talos with the workaround set
05:15karolherbst: imirkin: also do you want me to create a trace on lowest setting with "No Dynamic Lightning" enabled and one without? maybe its easier that way what is going wrong
05:15karolherbst: also it will only help the green wall isue
05:16mupuf: karolherbst: that sucks hard :o
05:17karolherbst: but I was wrong all the time about the cstates
05:17karolherbst: the pstate indeed sets the highest cstate, but I broke it while fixing cstate selection
05:18karolherbst: so it won't help any card at all except when the order of cstates is weird
05:18karolherbst: mupuf: but 25% is still pretty good
05:18karolherbst: it may make the difference for d3d9 games in wine :D I will test the d3d9 stuff inside wine now
05:23karolherbst: mupuf: do you know if the nvkm_clk_adjust function works in clk/base.c?
05:23karolherbst: I couldn't really figure out what parameters I should set for it
05:24mupuf: 25% is much worse than what we had during the nv50 era
05:25mupuf: but it has been a while since anyone looked at the performance
05:25mupuf: so there may be low-hanging fruits
05:30karolherbst: maybe I could get more with a little boost clocking. I never saw the nvidia reporting boosted clocks, so I don'T know how fast it will run
05:31karolherbst: also 0f state has more then doubled memory clock, so this may be a big performance hit
05:45karolherbst: mupuf: okay 0f is at 300% 07, so basically around 35% blob
05:47eijebong: Hi, I resolved my HUB_INIT timeout issue with the patch you pointed yesterday :) But « OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile », it didn't change anything here
05:49Samsai: karolherbst, i've seen performance up to 38% of the blob on my gtx 760
05:49karolherbst: Samsai: then I am not that far away anymore :)
05:49karolherbst: 0f is pretty unstable though and is likely to hang the gpu
05:49Samsai: but a lot more stable than it used to be
05:50karolherbst: I don't know, couldn't use be card before 4.1
05:50Samsai: back in april i only managed to access 0f in some extremely rare cases
05:50Samsai: now 8 out of 10 attempts are successful
05:51Samsai: not that 0f is particularly useful because it doesn't set cstate properly and only reclocks the memory
05:52Samsai: heaven benchmark runs faster on 0a for example
05:54karolherbst: Samsai: does both pstates don't set the gpu clock for you or only 0f?
05:54Samsai: karolherbst, 0a sets it to 967 MHz
05:54Samsai: but 0f keeps it at 405
05:54karolherbst: anything in dmesg?
05:55Samsai: when i reclock to 0f?
05:55Samsai: well, let's see if i don't blow my GPU up this time
05:55Samsai: [18819.464766] nouveau E[ CLK][0000:01:00.0] failed to raise voltage: -22
05:55karolherbst: I see
05:55karolherbst: know the problem
05:56Samsai: i noticed you talking about something similar earlier
05:56karolherbst: yeah, I have the same voltage problem
05:56karolherbst: so my card can't set the voltage at all
05:57Samsai: so you can't reclock the core clock at all?
05:57karolherbst: I can now
05:57karolherbst: but I can't set voltage
05:57karolherbst: you could remove this return statement: https://github.com/karolherbst/nouveau/blob/e87f21e3b1353e1960bac610ed3bde93e025b503/drm/nouveau/nvkm/subdev/clk/base.c#L110
05:58karolherbst: it will just skip setting voltage and set the cstate
05:58karolherbst: then it should also set the clock for you on 0f
05:58Samsai: i'd rather not mess with source files
05:58karolherbst: its still painfull, that the voltage stuff doesn't work
05:58karolherbst: weird that its works on 0a though
05:59karolherbst: Samsai: what does "dmesg | grep voltage" give you?
06:00karolherbst: mupuf: do you think its possible, that a card can set the voltage in theory, but fails on some states, because the requested voltage isn't there? Samsai has the problem, that clocking on 0a works, but not 0f, or do you know the problem already?
06:01Samsai: karolherbst, just the previous error and [ 11.356188] nouveau [ VOLT][0000:01:00.0] GPU voltage: 862500uv
06:01karolherbst: mhh interessting
06:02karolherbst: whats the max frequency of the 0f state?
06:04Samsai: karolherbst, for the cores it should be 1228 MHz
06:05karolherbst: I bet clocking itself works for you, but the voltage part doesn't find the right "mode" for the requested cstates and just fails
06:05Samsai: could be
06:05karolherbst: shouldn't be 0f be slower than 0a then?
06:05Samsai: in some cases it is
06:06Samsai: hl2 lost coast runs faster with 0f but heaven benchmark runs slower
06:06karolherbst: makes sense
06:06Samsai: i believe it depends on the computational complexity of the game
06:06Samsai: or benchmark
06:06karolherbst: mupuf, imirkin: it seems like this voltage fallback code should be finalized somehow, who has the "most ready" version of such currently?
06:07karolherbst: Samsai: yeah, some games only need fast memory, where other need fast gpu clocks
06:07karolherbst: with antichamber I get double performance in 0f compared to 0a for example
06:08Samsai: yeah, that makes sense
06:08mupuf: karolherbst: define voltage fallback
06:08karolherbst: and 0a and 0f have some core clocks for me
06:08mupuf: 0f should always be faster
06:08mupuf: the clocks only go up
06:08karolherbst: mupuf: if the exact one isnt' found, use the mode with a voltage a little bit lower
06:08karolherbst: mupuf: not for him
06:08karolherbst: 0f falls down to 405 MHz
06:09karolherbst: because voltage fails
06:09karolherbst: and cstate won't be set right
06:09mupuf: ok, then it makes sense
06:09karolherbst: but 0a clocks up
06:09mupuf: well, this should be trivial to fix
06:09karolherbst: mupuf: I have this: https://github.com/karolherbst/nouveau/commit/e87f21e3b1353e1960bac610ed3bde93e025b503
06:09karolherbst: but maybe somebody has somethig better already
06:11mupuf: well, your patch is wrong
06:12karolherbst: yeah, possible
06:12mupuf: if the cstate requires x uV, you should give it x or more
06:12mupuf: never less
06:12karolherbst: I though the voltage states always have min/max values
06:12karolherbst: and there only min is compared
06:13mupuf: well, max is stupid, min is the one you should care about
06:13mupuf: and set the voltage to at least mib
06:13mupuf: otherwise, bad things may happen
06:15karolherbst: mupuf: then what would be a good offset
06:15karolherbst: like 0.01V more is fine?
06:16mupuf: you seem to think that too much voltage is dangerous, stop being afraid of this
06:16karolherbst: or if the difference is about 1% its fine
06:16mupuf: as long as the GPU does not overheat, it is fine
06:16karolherbst: I was more like thinking about the table may contain wierd stuff
06:16mlankhorst: in general when you round up you do foo += next_step - 1; foo -= foo % next_step;
06:16karolherbst: and for me it contains 1.25V
06:16mupuf: but yeah, it is a good idea to add a warning
06:16mupuf: 1.25 is not weird
06:17karolherbst: my card usually runs at 1V
06:17karolherbst: or maybe 1.06V if you are up to it
06:17karolherbst: I was rading the overclocking thread of my card, an nobody went beyond 1.1V there
06:17mupuf: anyway, .05V seems like a good threshold for complaining
06:18mupuf: and .1V to complain loudly
06:18mupuf: but you can also simply check the max
06:18mupuf: if you are above max, then complain loudly and fail
06:19karolherbst: the table is quite weird for me, because like the highest sane one is somethig like 0.95 and then it jumps to 1.25 and if 0.96 is requested without such "offset2 it would jump to 1.25 and that might cause too much heat
06:19karolherbst: the thing is, I believe the 1.25 values are just wrong here
06:20karolherbst: highest sane: "-- ID = 47, link: 34, voltage_min = 900000, voltage_max = 1037500 [µV] --" higehst in table: "-- ID = 0, link: ff, voltage_min = 1250000, voltage_max = 1250000 [µV] --"
06:20karolherbst: also the link value is strange
06:20karolherbst: I think I will investigate a little further then
06:22karolherbst: mupuf: I remember: each cstate has a "voltage" value anyway, why not just force the entry it requested?
06:22karolherbst: if its not too bad
06:22karolherbst: anyway have to go, will think about it more
06:25mupuf: link: ff --> the entry is disabled
06:25mupuf: anyway, yo ushould have a look at the patch mlankhorst wrote for selecting the voltage
06:26mlankhorst: I still have the scripts for the steps too. :P
06:26mupuf: it was a bit more complicated than just selecting the lowest voltage possible that will be over voltage_min and under voltage_max
06:26mupuf: mlankhorst: nice
06:27mlankhorst: though still no clue where the constants come from..
06:27mupuf: as for myself, ... I still need to find where the heck is the PWM reg for the voltage
07:53sooda: hey, i need to read one numeric argument (size of a magic buffer read from a hw register at init time) to userspace. is a new mthd call appropriate for that, or could i add this to nouveau_abi16_ioctl_getparam, or something else?
08:06imirkin: what is the thing that you want to read out?
08:14mupuf: nouveau_abi16_ioctl_getparam sounds like a good place to expose this.
08:52mogorva: One of my games crashes the kernel driver (I think). Could you check my dmesg: http://hastebin.com/ewilusoxij.sm
08:53imirkin: hmmm... you're somehow getting blend setting changes in the middle of a draw? that's quite odd
08:54imirkin: looks like you ran out of memory
08:54imirkin: and nouveau isn't too great at handling oom conditions
08:54mogorva: doesn't happen with llvmpipe
08:54mogorva: or with the binary drivers
08:55imirkin: one of the issues is that we have unbounded gart
08:59imirkin: weird. those blend setting messages were from xorg.
08:59imirkin: will try to see if there's some logical way that could have happened
08:59imirkin: (but it's hardly the issue you're having)
09:00mogorva: can be reproduced with the trace too
10:11trey: does Nouveau support multi-stream transport currently? i'm using a displayport hub but the two monitors show up as mirrored and xrandr only shows the one output, i'm not sure how to configure it otherwise
10:25imirkin_: trey: not yet, but it's in the works i think
10:25trey: ah ok thanks
10:25imirkin_: mogorva: your hang can be reprod with the trace?
10:25sooda: imirkin_: the thing is a zcull buffer size. i'm also adding support for configuring it, but userspace needs to know the size first
10:26imirkin_: sooda: yeah that getinfo thing sounds good
10:26imirkin_: sooda: we have hypothetical (i.e. #ifdef'd out) support for zcull already
10:26imirkin_: i assume it didn't work properly :)
10:27sooda: it requires some magic init and also setting up that buffer, you probably have the init stuff?
10:27imirkin_: unfortunately i know next to nothing about any of that stuff, but happy to help understand the flow of the mesa driver if that's what you're looking at
10:27sooda: and the buf is just one "mode" for this. there is another that also optimizes stuff but is older
10:28imirkin_: sooda: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n7
10:28sooda: thanks. any idea what validation means in this context?
10:29imirkin_: so basically in the gallium api there are a bunch of ->set_blah() calls
10:29imirkin_: and then eventually there's a ->draw() call
10:29imirkin_: the draw call will basically flush out all the previous set's into actual command stream things
10:29imirkin_: that is called "validation"
10:30imirkin_: and the ->set calls set various dirty bits
10:30imirkin_: and various validation functions are triggered based on those dirty bits
10:30imirkin_: that way we don't re-emit the same state over and over again
10:31sooda: but yea that function looks different
10:32imirkin_: and the context init stuff is in nvc0_context.c and nvc0_screen.c
10:32imirkin_: (all gallium contexts share a single gpu context)
10:32imirkin_: and we really suck at multiple threads using multiple gl contexts at once :)
10:32imirkin_: but that never happens in practice, so wtvr
10:33pirea: i have a graphic card
10:33pirea: or tow
10:33pirea: nvidia gtx/gt 840m/850m
10:33pirea: and nouveau doesn't support them
10:34imirkin_: pirea: lspci -nn -d 10de:
10:34imirkin_: pirea: is it a GM108?
10:34pirea: 10de:1341 pci id
10:34mogorva: imirkin: yes, the crash can be reprod with the trace that I created
10:35imirkin_: yeah, someone (cough, skeggsb) has been lazy about processing the GM108 mmiotrace to figure out what init it does differently and adding the support
10:35imirkin_: pirea: you can mostly get it to work if you just add a "case 0x118:" above the "case 0x117:" in device/gm100.c
10:36imirkin_: pirea: however it's unlikely to provide you with any actual benefit in terms of perf since we don't have reclocking on maxwell
10:37pirea: ok :) tnx
10:37pirea: it's ok
10:37pirea: i just want to use nouveau
10:37pirea: not that binary blob :)
10:37imirkin_: the main benefit that nouveau will provide you is that it'll auto-shut the gpu off and you'll have more battery life
10:44mogorva: here's the trace: https://drive.google.com/open?id=0B-tTbLKBl-tOV05IWVo2aG5DcU0
10:53pirea: imirkin_ now i am recompiling the kernel
10:53pirea: tnx again
10:54imirkin_: pirea: you'll also need a 4.1 kernel if you want acceleration to work out of the box
10:54imirkin_: sorry, should have mentioned that earlier
11:11pirea: i have 4.0
11:12pirea: imirkin_ what means out of the box for nouveau?
11:13imirkin_: pirea: before 4.1, you needed to have blob ctxsw firmware installed in order to get acceleration
11:13imirkin_: and obtaining that firmware isn't very straightforward
11:14pirea: what is ctxsw?
11:15imirkin_: context switching
13:34librin: Imirkin, do You have a minute?
13:35imirkin_: i have many minutes.
13:35librin: regarding https://bugs.freedesktop.org/show_bug.cgi?id=90513
13:36librin: I have noticed the game warns about a shader compilation error
13:36librin: could that be relevant?
13:36imirkin_: is it the spill failure?
13:36imirkin_: (yes, it could be relevant, but i haven't seen it)
13:37librin: >23:31:49 WRN: Shader compiling error:
13:37librin: >23:31:49 WRN: 0:734(18): error: no matching function for call to `pow(vec3, float)'; candidates are:
13:37librin: >23:31:49 WRN: 0:734(18): error: float pow(float, float)
13:37librin: >23:31:49 WRN: 0:734(18): error: vec2 pow(vec2, vec2)
13:37librin: >23:31:49 WRN: 0:734(18): error: vec3 pow(vec3, vec3)
13:37librin: >23:31:49 WRN: 0:734(18): error: vec4 pow(vec4, vec4)
13:37librin: exactly this
13:37imirkin_: that's wrnog
13:37imirkin_: gimme a min
13:38imirkin_: oh wait, hm. it might be right.
13:38librin:just nods in slight confusion
13:39imirkin_: genType pow (genType x, genType y)
13:39imirkin_: ok, so there doesn't appear to be a pow(genType, float) variant
13:39librin: should there be one?
13:40imirkin_: there's various rules about things becoming automatically vectorized
13:40imirkin_: e.g. you can do vec4 + float
13:41imirkin_: unfortunately i'm insufficiently familiar with the upconversion rules of the spec
13:42imirkin_: librin: i can give you a patch that will temporarily solve that
13:42imirkin_: but it probably won't be the right approach
13:42librin: testing patches is a neat thing to do
13:43librin: if it would be of any help, sure, please do send me a patch
13:43librin: I mean, if it would be of any help figuring out what's wrong, yadda yadda
13:44imirkin_: er hrm
13:44imirkin_: it's not so trivial as i thought
13:53imirkin_: librin: that looks like a bug in talos :(
13:53librin: that's a possibility
13:54imirkin_: although quite likely separate from the red flicker one
13:54librin: imirkin_, I am going to talk to the devs about it
13:55imirkin_: you have a line to the talos devs?
13:55librin: imirkin_, actually, talking already
13:55librin: not sure how to approach this one though
13:56imirkin_: well, this is a straight up bug... glsl doesn't allow pow(vec3, float)
13:56imirkin_: you can use apitrace to dump out the shader whose compilation fails
13:57imirkin_: or MESA_GLSL=dump
13:57imirkin_: although that's going to be super-verbose
13:57librin: a quick how-to on how to do it with apitrace?
13:58imirkin_: you know how to capture a trace already right?
13:58imirkin_: then you can use 'apitrace dump' and find the glCompileShader (or glCompileProgram?) call which fails
13:58librin: yes and I captured a new one
13:58imirkin_: (or glShaderSource? i really suck at GL)
13:59librin: I can see the sources in glShaderSource calls
13:59imirkin_: if you maek the trace available, i should be able to find it pretty quickly
13:59librin: but not sure how to dump it – it just shows it all in tiny window
13:59imirkin_: ok, so you're looking for one that follows by a GL_INVALID_OPERATION or something
14:03librin: keep in mind that currently my DNS is down, so I'm feeding a bare IP, which should result into a security warning B(
14:03imirkin_: yea wtvr. already got it
14:09imirkin_: librin: http://hastebin.com/qevuqameco.cs
14:10imirkin_: vOutColor.rgb = pow(vOutColor.rgb, c_fGamma);
14:10imirkin_: _CregF( float, c_fGamma, 0);
14:10imirkin_: which declares it as a float
14:11librin: imirkin_, I was told to report it to their [closed] bug tracker
14:11librin: already on it
14:12librin: >(2015-07-09 00:10:19) AlenL: "4096x4096 srgb dxt1/5 textures, specifically" what's weird with that?
14:12librin: >(2015-07-09 00:10:43) AlenL: most of our textures are sRGB DXT, and a lot of them are huge :)
14:12librin: >(2015-07-09 00:11:38) AlenL: "Multiple vertex elements are mapped to the same position in the same buffer" i don't understand what he means
14:12imirkin_: librin: nothing bad about 4k x 4k dxt textures. it's just not something i've commonly seen. it's perfectly legal.
14:12imirkin_: however for all i know there's some hardware issue with it
14:12imirkin_: that's why i singled that out
14:13librin: I see
14:13imirkin_: vertex element was the wrong term
14:13imirkin_: i meant "multiple vertex attributes"
14:13imirkin_: which again is in no way illegal, just struck me as odd
14:14Karlton: imirkin_: could, you explain this? https://imgrush.com/Dxm8P-75OmHk
14:15Karlton: the one on the left is software only
14:15imirkin_: librin: btw, i may have gone overboard with the "as small as possible" request... you can barely see anything in your window size ;)
14:15imirkin_: make it a bit bigger... 640x480 should be a nice compromise
14:16librin: I actually wanted to go smaller
14:16imirkin_: Karlton: hmmm... interesting. the LATC texture is wrong?
14:16imirkin_: librin: well, it still spends a ton of time compiling the shaders, which is annoying
14:16librin: a bit hard to navigate the menu to load the game like this, though xD
14:17librin: I am not familiar with this acronym
14:17airlied: be back later
14:17librin: ah, right
14:35Karlton: imirkin_: well that is my flightgear trace and I was hoping to track down the green stuff and I found that
14:57Karlton: okay so, I see the LATC textures are failing everywhere :(
15:02Karlton: I am going to assume it wasn't failing on my NV50 card
15:09hakzsam_: imirkin_, oh crap, I forgot to add the cc mesa-stable for the vao-attrib fix, sorry...
15:13imirkin_: hakzsam_: no prob. just send an email to mesa-stable asking to cherry-pick that commit
15:21Karlton: the ones on the left are not labled as compressed
15:21Karlton: what does that mean?
15:21imirkin_: Karlton: huh? what do you mean by "labeled"?
15:22Karlton: in qapitrace
15:22imirkin_: where is the label?
15:23Karlton: like on the right they say GL_COMPRESSED_LUMINANCE_LATC1_EXT, 1x1
15:23imirkin_: and on the left?
15:23imirkin_: it's just GL_LA
15:23Karlton: on the left it just says GL_LUMINANCE
15:24imirkin_: try running with MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_compression_latc
15:26Karlton: for which one? hardware?
15:26imirkin_: i mean... the format should be a function of the trace
15:26imirkin_: not of the renderer you run it on
15:28Karlton: it still says compressed
15:28imirkin_: right... coz that's what the trace calls for
15:28imirkin_: are they the same trace?
15:29Karlton: extactly the same trace except on one I used LIBGL_ALWAYS_SOFTWARE=1
15:29imirkin_: very odd.
15:30imirkin_: the format of the texture is dictated by the GL calls, not by any driver details
15:33boxfire: skeggsb: just a poke about TMDS speed > 165 MHz through display port
15:33imirkin_: boxfire: if you want, you could probably speed things along by recording an mmiotrace of the blob driver setting it all up properly
15:36imirkin_: hakzsam_: were you planning on finishing up the nv50-related piglit runs?
15:39hakzsam_: imirkin_, I'll try tomorrow
15:42Karlton: imirkin_: I am going to see what it looks like on intel...
15:42hakzsam_: imirkin_, I was trying to fix up other piglit tests :)
15:42imirkin_: hakzsam_: hehe
15:43imirkin_: well i fixed one yesterday by fixing the piglit itself ;)
15:43imirkin_: the sample-depth one for ms textures
15:43hakzsam_: imirkin_, for sure, I have to finish the piglit runs tomorrow because after I'll be on vacation for one ~week
15:44imirkin_: you're lookign at the point-vertex-id one?
15:44imirkin_: i'm not sure why i marked it "easy"
15:44imirkin_: i think it might be the same issue as https://trello.com/c/DZvNunjG/93-nv50-vertexid-drawarrays-and-drawelements
15:45hakzsam_: yeah, I tried to figure out what happens with that success, but no clue yet
15:45hakzsam_: I was trying to fix the tfb issues on nva0+
15:45hakzsam_: *with that test :)
15:46Karlton: imirkin_: on intel it looks fine and says GL_LIMINANCE_ALPHA,1x1
15:46hakzsam_: imirkin_, well, I'm tired, see you later
15:46imirkin_: hakzsam_: oh oops. i've already fixed those.
15:47imirkin_: hakzsam_: but i don't like the way i fixed them
15:47boxfire: imirkin_: I can try that tonight when I go home in 4 hours. Any pointers on what to do or is googling mmiotrace going to get me enough info?
15:47imirkin_: boxfire: https://wiki.ubuntu.com/X/MMIOTracing
15:47imirkin_: just need a trace of it bringing the screen up at the desired resolution
15:48boxfire: imirkin_: k. Ill be doing that later tonight and putting the results on the ticket I filed
15:48imirkin_: sounds good. a successful mmiotrace should be 30-50MB uncompressed
15:48imirkin_: ideally you'd put it up somewhere, or email it to email@example.com
15:51hakzsam_: imirkin_, with https://github.com/imirkin/mesa/commit/c01bb891221e3cd3e030fc33042fd32a80a19cc4 ?
15:51hakzsam_: the test still fails
15:51hakzsam_: nouveau_bo_wait() seems to partially fix the issue
15:51hakzsam_: but there is still a problem
15:51imirkin_: boxfire: xz -9 compresses it down nicely though
15:51imirkin_: hakzsam_: no, that was an early attempt. i have something that fixse it for real
15:54Karlton: imirkin_: intel and software looks like this: https://imgrush.com/CXBDmIWwx4i1 , while nouveau looks like this: https://imgrush.com/FHgrotGMX7LX
15:58karolherbst: mupuf, imirkin_: another one: https://bugs.freedesktop.org/show_bug.cgi?id=88890
16:04imirkin_: Karlton: i am perplexed as to why it says la for intel/software and latc for nouveau
16:06Karlton: imirkin_: I can't explain it either, but I know it is happening, and I think that might be why I see the green stuff
16:06imirkin_: could be
16:27Karlton: imirkin_: it can't be mesa right? because of MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_compression_latc did nothing
16:27imirkin_: i have no idea :(
16:27imirkin_: i'm actually a little curious where it gets the format information from
16:27imirkin_: does ARB_internal_formatquery have it
16:28imirkin_: hm doesn't look like it
16:32imirkin_: Karlton: can you confirm the command line for trying to disable latc?
16:35Karlton: I did "MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_compression_latc qapitrace fgfs.trace"
16:36Karlton: still the same thing
16:36imirkin_: that seems oddly correct
17:34imirkin_: librin: btw, if you could get the talos people to extend a "free games for mesa devs" thing, i wouldn't be against it :) valve has done it for their games
17:36librin: imirkin_, I don't get it ·_·
17:37imirkin_: librin: http://lists.freedesktop.org/archives/dri-devel/2015-April/081045.html
17:37imirkin_: you mentioned you knew the talos guys (croteam?)
17:39specing: meanwhile, there are more devs than players on open source games
17:39librin: imirkin_, Croteam indeed. And I could, in theory, suggest something like this to them. But I OFC can't promise anything...
17:40imirkin_: librin: yeah, of course. just floating the idea.
17:40imirkin_: i certainly know i'm not going to *pay* to fix bugs that their games hit
17:41imirkin_: but i was able to fix a few bugs that e.g. portal hit because of the valve program
17:42imirkin_: specing: if only that were true of open graphics drivers
18:08specing: well, the more players there are, the more turn into game devs, the more end up being frustrated with the whole graphics stack and the more end up fixing drivers
18:09imirkin_: i'm aware of only one game engine dev who works on graphics drivers
18:09imirkin_: the rest came to it via very different paths
18:10specing: imagine that, waking up one morning and thinking..."now Im going to fix mesa once and for all, whatever that is"
18:10imirkin_: i suspect that's none of the current mesa devs :p
18:11specing: also what is your sample size?
18:11imirkin_: all active mesa devs
18:11specing: I mean for < imirkin_> i'm aware of only one game engine dev who works on graphics drivers
18:11imirkin_: i guess i dunno for sure about each of them, but i've probably spoken a bunch to all of them, and the game engine thing has only come up with one
18:12imirkin_: there aren't exactly a lot of active mesa devs, so it's not some herculean effort :)
18:18specing:still doesen't know what mesa is for except it wants to install radeon stuff on an nvidia machine
18:18mwk: <3 VLIW
18:18imirkin_: mwk: some day you'll be ready to graduate to vp2 :)
18:19imirkin_: i think nvidia produces these things faster than you re them
18:19mwk: yeah, that one is going to be fun...
18:20mwk: imirkin_: given that I haven't been REing stuff at all for like a year, that's about right
18:20imirkin_: specing: http://mesa3d.org/intro.html
18:24specing: so basically it is a passthrough/translation layer to introduce lag?
18:25imirkin_: yep, that's the sole purpose
18:26airlied: pretty much the description of OpenGL
18:28imirkin_: specing: pretty much the purpose of any library, really
18:30specing: I've read somewhere about openGPU efforts on an FPGA
18:31specing: I would assume that would be easier in the long run than reverse engineering
18:31imirkin_: you've never tried to use an FPGA i assume
18:32imirkin_: nor are you familiar with the performance differences between FPGAs and ASICs
18:32specing: I have
18:32specing: and yes it would suck compared to market gpus
18:32imirkin_: on _so_ many levels
18:32imirkin_: and you'd *still* be stuck making drivers
18:32specing: I meant 'easier' from the software/drivers perspective
18:33specing: ah ok
18:34imirkin_: the thing you're probably thinking of is OGD or something along those lines
18:39imirkin_: sooda: btw, just happened to remember this -- it sorta seems like you're working on improving the mesa driver if you're talking about things like zcull. if you are, let me know, there are a few other fails i'm aware of that could be worth 10-30% in perf.
18:39specing: ah yes
18:40mwk: if you write $r from more than one instruction in a single bundle, the scalar one gets priority, unless it happens to be "move special register to $r", in which case the address one gets priority...
18:41mwk: ah VP1, I missed you and your crazy rules
18:41imirkin_: heh. the real question is whether you can do anything useful with it
18:41imirkin_: not the interaction
18:41imirkin_: but VP1 in general
18:42mwk: that's what I mean
18:42mwk: I mean, I could perhaps implement a good portion of MPEG2 or maybe even H.264 on it
18:42mwk: but honestly what's the point...
18:42imirkin_: well, def no point in mpeg2
18:43imirkin_: since the hw has a dedicated mpeg2 decoder
18:43imirkin_: but from the soudns of it, the video "accelerator" for h264 wasn't much good either, at least with the nvidia fw
18:43mwk: well, we could throw in IQ
18:43mwk: but that's like the least interesting part of MPEG-2
18:44mwk: well yeah
18:44mwk: everyone seems to agree it's utter piece of shit
18:44mwk: including nvidia... there was never a vdpau implementation
18:45imirkin_: well, there was a windows thing for it
18:45imirkin_: DXVA? whatever it was called
18:47mwk: Mismatch on try 125960 for insn 0x421e5878 0xead0ce62 0x7edb81aa 0x7439eacb
18:49imirkin_: mwk: btw, i'm considering trying out some instruction scheduling stuff. any advice on it?
18:49imirkin_: other than obviously trying to maximize things like dual issue
18:50mwk: imirkin_: no... I haven't tried that stuff at all
22:55boxfire: imirkin_: right. Nvidia blob isnt DRI3.... is it possible to set its mode without demanding my bios boot nvidia only (making it moderately annoying at the very least)?
22:56imirkin_: boxfire: sorry, dunno blob specifics.
22:56imirkin_: normally you'd need to start X or something
22:56imirkin_: pointed at the nvidia gpu
22:56imirkin_: don't think it matters whether it's primary or secondary... just have to get the x config right
22:57boxfire: yeah, but on my laptop only the intel gpu is attached to the LVDS
22:57imirkin_: first do it without mmiotrace, since mmiotrace will super-slow it down
22:57imirkin_: well, the whole point is to get it to modeset on the DP->HDMI thing
22:57imirkin_: so LVDS is irrelevant
22:57boxfire: so rebuild a kernel with vesa and set the bios. okay.
22:57imirkin_: huh no
22:58imirkin_: craft an X config that only uses the nvidia gpu
22:58imirkin_: and start it up
22:58imirkin_: and have it modeset the HDMI port
22:58boxfire: imirkin_: https://xkcd.com/963/
22:58imirkin_: something like http://hastebin.com/uherunosum.cmake