02:10hakzsam_: imirkin, mmt is broken with nouveau, no nvif support
02:13hakzsam_: airlied, the gallium interface for compute shaders fits just well for nouveau
02:13hakzsam_: I need to have a look at the series which slightly changes the interface
02:19hakzsam_: imirkin, btw, if you want to check piglit results on gf119 with mesa-11.2.-rc4 https://people.freedesktop.org/~hakzsam/piglit/
02:19hakzsam_: it looks fine
02:19hakzsam_: we did not break the universe :)
03:00braveheart2: t i r e d o f j e w s, l i e s , a n d b a d s o u n d? a d d m e t o t o x. m y i d i s E E E D E 7 2 B 6 1 8 7 4 2 5 7 0 0 F C A 0 7 D 1 B 3 F C 2 D 4 9 C 6 C 5 B 6 B D A E F A 8 1 9 D 3 5 9 7 6 E 8 8 6 0 B 2 E 7 D F D F 6 F C 4 9 E A F 5 remove spaces!
03:04pq: K-line! \o/
03:07j_ewsbanu: t i r e d o f j e w s, l i e s , a n d b a d s o u n d ? a d d m e t o t o x. m y i d i s E E E D E 7 2 B 6 1 8 7 4 2 5 7 0 0 F C A 0 7 D 1 B 3 F C 2 D 4 9 C 6 C 5 B 6 B D A E F A 8 1 9 D 3 5 9 7 6 E 8 8 6 0 B 2 E 7 D F D F 6 F C 4 9 E A F 5 r e m o v e s p a c e s ....
04:47martm: hi guys, i tried to read the caching code for nouveau, it turns out that intel's caching regs are exposed to opencl shaders, and probably also the same thing goes to amd, i mean not lds, but also constant and texture caches can be accessed so for intel, that it can do bookeeping in the shader that of a cache
04:49martm: but.. nouveau seems to use some ring buffer preloading in the driver, which is expected & it does not have any opencl implementation, and i am bit vague about how to access cache circuit regs in the nouveaus shader hence
04:50martm: once that is resolved howto do that, it takes me quite some time if some experts of nouveau ain't gonna help me there how to do that scheme
04:50martm: than the scheduler can be done right
04:54martm: I am not sure , maybe the scartch regs are the ones that could be used both in ringbuffer and shader processor, i could be off here, it needs more reading since practically noone has talked to me
04:56martm: the other idea is that calim has a minor comments that threads can exchange information somehow even being run on different shader processors SM
04:57martm: maybe it can have that sort of mechanism to expose cache regs too, however really in a time hurry here, i belive needs some week of reading the stuff yet about nouveaus cache handing, it seems tics are the offsets into the real backing regs
04:58martm: PUSH_DATA (push, 0x1001);
04:58martm: PUSH_DATAp(push, &tic->tic, 8);
06:11RSpliet: karolherbst: I see your nvbios patches haven't been merged yet... sorry, I didn't give them a proper review (swamped, unfocussed...)
06:12RSpliet: are there any blockers on the patch-set?
06:15martm: RSpliet: do you happen to know how far the nv98 chip can be reclocked, to maximum or what is the state there?
06:19RSpliet: martm: some GDDR3 cards can be clocked up to max with the latest kernel, but the best way to find out is to try
06:19martm: ok, thanks..
06:29martm: with the cache the job looks almost even easy, i am only still looking which function returns the physical address that is stored at that index of a slot, it's definitely there, but i dunno which one is it yet, there is reading writing status and tic invalid codes returned
06:29martm: there is definitely a way to get the physical address too, intel has it too
06:31martm: though, it probably gives a virtual address of course there not the physical page address of a memory
07:38imirkin: hakzsam_: there's a way to force it not to use the new ioctls... might have to add an env var
07:41martm: maybe it is tic element from tic array, that stores the address, not sure how to ask that address is from a shader though
07:41martm: that/what the
08:03hakzsam_: imirkin, I know, but the last time I tried that didn't work
08:03hakzsam_: will try again
08:07martm: BCTX_REFN(nvc0->bufctx_3d, TEX(s, i), res, RD); but there it is res
08:10martm: imirkin: mind helping me a bit, how can i ask what address is in the cache slot using ringbuffer method?
08:12imirkin: hakzsam_: fwiw i also tend to have to do LIBGL_DRI3_DISABLE=1
08:19hakzsam_: imirkin, so, what do you want me to change for the driver cb patch? :)
08:22karolherbst: RSpliet: no problem
08:23imirkin: hakzsam_: i want you to stick ms_offsets and grid_info after tex but below 0x100
08:23imirkin: it should just fit, with 1 word to spare
08:23imirkin: and then stick UBO's at 0x100..0x200
08:24imirkin: which should not require any driver cb space increases
08:24imirkin: unless i miscounted the size you need for UBO's
08:25hakzsam_: no, this should work
08:26imirkin: i know we'll have to bump the size for surface infos, but... let's not do anything prematurely
08:31martm: i think i've done with the research of cache on nouveau allready, but i could be quite dumb newby, in a sense that i do not know elementary things still..there are two possibilities from which one should work
08:32martm: stared at the code three hours or so!
08:45vedranm: hi guys
08:45vedranm: I'm trying to get Intel+nouveau DRI_PRIME to work
08:46vedranm: this is 750M and it's correctly recognized by nouveau, shown in --listproviders
08:46vedranm: --setprovideroffloadsink works
08:46vedranm: but DRI_PRIME=1 glxinfo still gives Intel
08:46vedranm: any ideas?
08:47karolherbst: vedranm: use dri3
08:48karolherbst: vedranm: and maybe use this xorg conf when the intel ddx doesn't want to run under dri3 by default: https://gist.github.com/karolherbst/1f1bdd1a3822df74097f
08:48karolherbst: though the second device entry is optional and more usefull for devs who want to unload nouveau while X is running
08:49karolherbst: vedranm: with dri3 you don't need those xrandr commands anymore, because it just works
08:50vedranm: karolherbst: what do you mean "just works"? I run glxgears and it uses nouveau?
08:50karolherbst: well you still need DRI_PRIME
08:50vedranm: I see
08:51karolherbst: but there is a way to force a set gpu for apps, I think you can set something like that in driconf
08:52vedranm: karolherbst: OK
09:09hakzsam_: imirkin, for indirect draw, you call nouveau_pushbuf_space() just before PUSH_REFN
09:09hakzsam_: this is exactly what I do
09:09hakzsam_: I guess it's correct
09:09hakzsam_: except that I forgot one call to nouveau_pusbuf_space() but I have fixed it locally
09:11hakzsam_: imirkin, so, I think the v3 is ready to go
09:12Yoshimo: is the deqp test still needed on a gm2x?
09:13hakzsam_: Yoshimo, if you have mesa master, yes :)
09:13hakzsam_: and piglit
09:14Yoshimo: not completely compiled yet, i had to download mesa master again as i only had an incomplete gallium nine ixit master
09:15hakzsam_: okay, please tell me when it's done
09:15karolherbst: ohh no, it is that day again...
09:16Yoshimo: friday, the day before weekend ;)
09:59karolherbst: mupuf: when nvidia hits the max temperature, it just downclocks to minimum, right?
10:00karolherbst: at least for me it does
10:29mupuf: can't remember
10:29mupuf: actually, no, it did not
10:46Yoshimo: so mesa compiled, now things are starting to get interesting
10:55Yoshimo: if i compiled my own mesa, how can i make sure that it replaced the one that i installed from my distro? the glxinfo still mentions the oibaf ppa after rebooting after a successfull Make install in the mesa dir
10:57karolherbst: mupuf: huh? I just tested and when I hit 97°C it clocks down to min clocks
10:57mupuf: not on my desktop GK106
10:57karolherbst: mupuf: what does it do there?
10:58mupuf: it downclocks to the baseclock
10:58mupuf: and lets the FSRM handle the rest
11:00karolherbst: mupuf: 96°C: max clocks, 97°C 07 pstate max
11:00karolherbst: and with 100 the fsrm hits in
11:02Yoshimo: what does deqp mean by FATAL ERROR: Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egluNativeDisplay.cpp:70 ?
11:02mupuf: Yoshimo: ah right, this error
11:03karolherbst: mupuf: but maybe your temperature range is a bit bigger and it scales the clock depending on the temperature in a base-min range or something
11:03mupuf: Yoshimo: commenting the line is usually enough
11:03mupuf: that would be weird
11:03mupuf: but there may be information about that in the vbios, indeed
11:03mupuf: maybe just a bit
11:03mupuf: but you know what?
11:04karolherbst: we just clock to min and be done with it? :D
11:04mupuf: add a /* TODO */
11:04mupuf: stating that nvidia does not always do that, but until we figure it out, we will be on the safe side
11:05karolherbst: mhh I plan to remove the dstate and tstate to simplify the clock cstate selection ahdnling
11:05mupuf: what are these again?
11:05karolherbst: display and temperature
11:05karolherbst: display is handled by PMU counters on gt215+ no idea how on older chips
11:05karolherbst: we just get a high memory load
11:05karolherbst: and upclock memory so that it fits
11:06karolherbst: no need to calculate on a bogus assumption which pstate we need
11:07Yoshimo: mupuf: which file is it in? dolphin can't find a match
11:08karolherbst: and temperature will be handled through the 1s daemon inside nouveau anyway somewhat
11:08karolherbst: in the end we just need a different interface maybe
11:12karolherbst: maybe nvkm_clk_enable_heat_downclock(clk, percentage) and percentage is between 0: <= temp_max_clock and 100: > temp_min_clock
11:37Yoshimo: if running piglit tests freezes the machine, which files would be needed for analysis?
11:39RSpliet: Yoshimo: is that consistent? tried running it on a single CPU?
11:40Yoshimo: well consistent mhmm, if the machine rebooted and i try to run it again it freezes again, not sure if it is the same test each time
11:41RSpliet: There are some known threading-related issues with nouveau (which in hindsight might have made a great GSoC project :-P)
11:41RSpliet: you might want to try running piglit single-threaded if it isn't already
11:41RSpliet: or well, that's my first guess
11:42martm: RSpliet: well that is what i thought, that maybe those are threading issues, maybe the underlying problem is non-coherant l1 cache, but this can be disabled on nvidia cards
11:43martm: wonder if anyone ever tried to disable the cache, i think it gives the regs to shared memory and stack, was it 48 and 16kb respecively or something like that
11:44martm: shared memory in opencl terms, is cached local memory as i understand though, the l1 cache can cause deadlocks
11:44martm: so called user-configurable cache some may call it like that
12:07karolherbst: mupuf: uhhh, the tegras also do their PMU counter on the CPU currently...
12:08karolherbst: how is the PMU situation there? Do they also get the nouveau pmu code?
12:09karolherbst: or is there no pmu
13:00hakzsam_: Yoshimo, what command did you use for piglit?
13:00Yoshimo: run all
13:01hakzsam_: okay, usually we use ./piglit-run.py -1 --dmesg tests/gpu.y
13:01hakzsam_: -1 prevent use of concurrent tests
13:02Yoshimo: ok i will try that one later
13:03Yoshimo: hakzsam_: any idea why i still have traces of oibafs ppa in glxinfo after compiling mesa-master and make install?
13:03hakzsam_: and when the gpu hangs it's not really cool because it's not always the latest test which breaks the universe
13:03hakzsam_: "oibafs ppa" ? what's that?
13:03hakzsam_: Updated and Optimized Open Graphics Drivers
13:04hakzsam_: ah okay
13:04hakzsam_: Yoshimo, did you set up LD_LIBRARY_PATH?
13:05Yoshimo: i think it was filled, i am not entirely sure though, will have to verify
13:06hakzsam_: yeah, you should have something like "Mesa 11.3.0-devel (git-XXXXX)"
13:08Yoshimo: compiling myself shouldn't be necessary though, that archive updates drivers and mesa every 12h iirc
13:09hakzsam_: yeah, you will be able to test compute shaders on your maxwell in few days then
13:09hakzsam_: I'm going to push the series
13:10Yoshimo: is the deqp crash because you haven't pushed yet?
13:10hakzsam_: which crash?
13:11Yoshimo: if i start the -31 test i was told earlier this week, it says "application crashed, memorydump written"
13:11hakzsam_: probably not because compute shaders are only exposed if you use some magic mesa envvars
13:12hakzsam_: nope, this is most likely unrelated
13:12hakzsam_: anyway, it would be very good to have a full piglit run on your gm20x
13:13Yoshimo: bbl with a single threaded run
13:28hakzsam_: compute shaders for Kepler/Maxwell pushed!
13:28hakzsam_: if someone want to test, do not forget to use MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader and MESA_GL_VERSION_OVERRIDE=4.2
13:29hakzsam_: now, images :)
13:40imirkin_: hakzsam_: what's the issue with nvf0?
13:40imirkin_: iirc i had to have some patches when i was testing it on my gk208 a while ago
13:41imirkin_: unfortunately i appear to have misplaced that patch
13:41hakzsam_: imirkin_, tests/spec/arb_compute_shader/execution/basic-texelFetch.shader_test hangs the gpu
13:41hakzsam_: I suspect the tex instruction to be wrong there
13:41imirkin_: oh. that's unfortunate.
13:41hakzsam_: but it's the *only* test which fails
13:41imirkin_: but what it lacks in quantity it more than makes up for in quality of failure :)
13:42hakzsam_: sure, that's why I didn't enable compute shaders for this chip :)
13:42hakzsam_: imirkin_, if by chance you want to have a look, feel free to fix the issue
13:42hakzsam_: anyway, I'll try again later when the gk208 will be plugged in reator
13:42imirkin_: thank you for the gracious offer
13:43hakzsam_: hehe :)
13:43imirkin_: btw, did you have a look at the nv50 regressions yet?
13:43karolherbst: ohh gk208 in reator, nice
13:43hakzsam_: karolherbst, not yet
13:43hakzsam_: imirkin_, a little bit, you?
13:43karolherbst: yeah I know
13:43imirkin_: hakzsam_: not yet
13:43imirkin_: hakzsam_: what regressed?
13:43hakzsam_: I don't remember
13:44karolherbst: hakzsam_: I just hope they also have the new clocking bits the nvf1 has
13:45hakzsam_: imirkin_, are you going to have a look today?
13:45imirkin_: dunno, tbd
13:54hakzsam_: imirkin_, btw, deqp images on gk104 is not so bad -> [735/735] pass: 410, fail: 282, dmesg-fail: 17, crash: 26 \
13:56imirkin_: not *perfect* though
13:56hakzsam_: sure :)
13:57yoshimo: so test 9207 froze the machine again
13:58imirkin_: as in the machine froze again, which happened on test 9207, or test 9207 hung the machine again?
13:58hakzsam_: and what's the name of that 9207 test?
13:59hakzsam_: it should be marked as incomplete, maybe
13:59yoshimo: i can only see the statistics with warn, pass failed, but i will upload the current results
14:01yoshimo: the first one, because i didn't keep track on the first run imirkin_
14:02imirkin_: yoshimo: at the very end of the results file
14:02imirkin_: it should be clear what the last test that executed was
14:02imirkin_: er hm. maybe not the way it's done nowadays
14:03yoshimo: http://workupload.com/file/ZbLe3hd for the results folder
14:04imirkin_:doesn't do ads
14:04imirkin_: maybe try a site like filebin.ca?
14:05hakzsam_: "Please, don't use an adBlocker on our site." ...
14:05imirkin_: moral of the story: don't use their site.
14:05yoshimo: strange, i don't even get blocked elements shown ;)
14:08hakzsam_: yoshimo, you need -x max-texture-size
14:08hakzsam_: this test is expected to crash actually
14:09hakzsam_: sorry I forgot to tell you that
14:09imirkin_: yoshimo: here are the instructions for not having it crash btw: https://people.freedesktop.org/~imirkin/
14:09imirkin_: max-texture-size is a good one to kill off as well... streaming-texture-leak is the big bad one though
14:09imirkin_: and the glx tests also tend to do bad things
14:11yoshimo: i can reccomend reeks antiadblock killer btw, hides that warning you got
14:11imirkin_: i dunno. that site doesn't want me to use it, so... i won't
14:11imirkin_: problem solved.
14:11yoshimo: just in case you need it somewhere else
14:11yoshimo: so lets re-do the test
14:12imirkin_: oh, i can always defeat it when i need to
14:14yoshimo: these tests care about active screensaver, don't they?
14:14imirkin_: mmmmmmmm dunno
14:14imirkin_: i'm not 100% sure what a screensaver does
14:15imirkin_: oh, you can run these with PIGLIT_NO_WINDOW=1 in the environment
14:15imirkin_: which will reduce the number of stupid little windows that pop up
14:22yoshimo: they are gone fast enough and they don't grab the focus, so it is fine
15:47jayhost: karolherbst Playing skyrim wine on your nouveau branch gm107 with PS3 controller. Mind blown a little
15:51karolherbst: jayhost: why? :D
15:52karolherbst: ohh I've added the boost stuff to that branch by the way
15:52karolherbst: you can somewhat change the max clocks
16:03jayhost: Oh nice. I havn't updated it for a month. It's mind blowing for me because it works just like a Winblows installation.
16:23karolherbst: nice to hear
16:31karolherbst: jayhost: if you want you could mmiotrace nvidia and nouveau both clocking from min to max and then compare the SEQ scripts
16:54szt: Hello peepz, I'm having weird freezes with the driver on random occasions
16:55szt: My GPU is the GTX 550 Ti
16:55karolherbst: szt: dmesg after a freeze
16:57szt: karolherbst: how? I can not do shit when the freeze occurs
16:57szt: xorg hangs
16:57karolherbst: szt: maybe ssh works
16:58szt: oh right, in fact it does
16:58szt: I will see what it says in there if it happens again
16:58karolherbst: how often does it freeze?
16:58szt: hm.. like once or twice every day
16:58szt: sometimes it stays stable for 3 days
16:59szt: as I said it's very inconsistent
16:59karolherbst: I see. what kernel and mesa version are you using?
16:59szt: Linux cybernode 4.1.20-1-lts #1 SMP Fri Mar 18 17:26:44 CET 2016 x86_64 GNU/Linux
16:59szt: Error with command 'mesa -v'
17:00szt: mesa 11.1.2-1
17:00karolherbst: at least mesa is new enough
17:01szt: yeah I'm using the lts
17:01karolherbst: maybe you could also use a newer kernel?
17:01karolherbst: with nouveau that is usually a good idea
17:01szt: but I keep having issues with the newer one
17:01karolherbst: not with older ones?
17:02szt: What was I thinking when I set my /boot to have just 100M
17:02karolherbst: well sometimes new features are added, but they break in some corner cases...
17:02szt: I can not have 2 kernels in there at once lol
17:02karolherbst: ohh 100M is plenty :D
17:02karolherbst: for 3-4 kernels
17:02szt: maybe there's junk in there
17:02karolherbst: my boot is 100Mb
17:02karolherbst: and only 23MB used
17:04szt: Filesystem Size Used Avail Use% Mounted on
17:04szt: /dev/sdb1 93M 58M 33M 65% /boot
17:04szt: df: '|': No such file or directory
17:04szt: df: grep: No such file or directory
17:04szt: I fail today
17:04szt: /dev/sdb1 93M 58M 33M 65% /boot
17:05szt: it's pretty much filled up
17:06szt: Ah I think I know what's causing this
17:06szt: the ext4 reserved space
17:13szt: karolherbst: what distribution are you using?
17:28karolherbst: szt: gentoo
17:29karolherbst: szt: maybe there are old kernels installed?
17:29szt: there's a fallback one
17:29szt: and the one I'm using
17:53jayhost: karoherbst what will SEQ scripts give us. Timings?
17:54karolherbst: jayhost: no, just to compare stuff
17:54karolherbst: jayhost: maybe there is something different on maxwell
17:55karolherbst: jayhost: just remember to mark in nvidia when it clocks to min, because it usually boots with higher clocks
17:55imirkin: jayhost: SEQ scripts are the scripts that tell the GPU-side PMU RTOS how to reclock
17:55imirkin: a script is generated by the host for each reclock
17:55imirkin: based on current state
18:15imirkin: gnurou: are you answering any questions on your github issues thing?
18:19karolherbst: imirkin: well I think others could answer as well
18:19karolherbst: imirkin: got a random answer for my zcull question...
18:19imirkin: it was more like "are questiosn getting answered"
18:19karolherbst: well mine did kind of...
18:20imirkin: tbh i don't really care who does the answering :)
18:20karolherbst: well the answer was a bit technical, but not enough for me to udnerstand
18:20karolherbst: maybe you do
18:21karolherbst: it would explain the rather weird behaviour of the blob
18:23imirkin: iirc that comment is disconnected from your question
18:23imirkin: your question is "how does zcull work"
18:24imirkin: the thing he's talking about is some implicit zcull thing that happens on ctxsw
18:24imirkin: which is useful information after you understand how zcull works
18:24imirkin: but not before
18:24karolherbst: he talked about the error I mentioned though
18:25imirkin: he talked about an error that one might get
18:25imirkin: but your question is way too generic for them to answer anyways
18:26karolherbst: I plan to work on some Z buffer stuff after I am done with my reclocking code anyway. I will try to write a Z buffer benchmark or something where nouveau is really bad, but nvidia really good
18:26karolherbst: yeah I know
18:26imirkin: they're a lot better at saying what register xyz does
18:26imirkin: than explaining how a larger feature functions
20:19jayhost: karolherbst had you figured out how to get mmiotrace working with nouveau?
21:05karolherbst: jayhost: same way
21:56jayhost: What do you mean?
21:58jayhost: Btw skyrim update. Wrote Python alias to start Skyrim in Steam offline mode and without Bethesda Credits. So startup is relatively instantaneous.
22:02karolherbst: jayhost: you trace nouveau the same way you trace nvidia
22:06jayhost: Yes but as I recall our last conversation regarding mmiotrace is that it breaks on the newest kernel
22:07jayhost: So I can trace the blob on old kernel but not nouveau
22:08imirkin: karolherbst: can you trace another deqp for me?
22:08karolherbst: jayhost: I fixed it
22:08karolherbst: jayhost: should be there in 4.5
22:08imirkin: karolherbst: dEQP-GLES31.functional.shaders.sample_variables.sample_mask_in.bit_count_per_two_samples.multisample_texture_8
22:09karolherbst: jayhost: ohh, no it will be there with 4.6
22:09imirkin: [also, let me know if it fails...]
22:10jayhost: karolherbst: oh wow good job. Also I think we should work on Nouveau documentation to make nouveau-dev newb friendly.
22:12imirkin: karolherbst: perfect thanks
22:12karolherbst: first run: 930ms compile time, second run: 0.3ms :D
22:13karolherbst: jayhost: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/mm/kmmio.c?id=cfa52c0cfa4d727aa3e457bf29aeff296c528a08
22:13imirkin: karolherbst: does it pass?
22:14imirkin: oh what?!!! grrrr
22:14imirkin: they cheat
22:14jayhost: I suggest MMIOTRACE moves to envytools.
22:14karolherbst: jayhost: :D
22:14imirkin: jayhost: it's in the kernel. it's a kernel tracer...
22:14karolherbst: it is based on page faults
22:15karolherbst: there can be userspace page fault handlers
22:15karolherbst: since 4.5 or something
22:16karolherbst: imirkin: why do they cheat?
22:16imirkin: because they are cheating cheaters who cheat
22:17imirkin: so... this thing was supposed to so sample shading = 0.5, which should translate to each invocation covering 2 samples
22:17imirkin: (with 8x ms)
22:17imirkin: which is something that the hw supports btw
22:17imirkin: so i wanted to see how they computed gl_SampleMaskIn for that, since it wasn't clear to me how that was handled
22:17imirkin: what do they do? they round up the sample shading ratio to 1, so each invocation only covers 1 sample (which is legal according to the spec btw)
22:19jayhost: imirkin I don't know if you figured out that mesa 11.2 thing but if you can write up some instructions on how to write over system installation I will give it another shot
22:19imirkin: jayhost: you shouldn't be writing over the system installation
22:19imirkin: that leads to no end of trouble
22:20imirkin: https://nouveau.freedesktop.org/wiki/InstallNouveau/ has some instructions on how to build things
22:20jayhost: Basically If I glxinfo after new install it gives mesa 11.1.2
22:21karolherbst: jayhost: never overwrite system libraries, this opens a world of pain you _don't_ want to deal with
22:21imirkin: moral of the story: follow the instructions
22:21karolherbst: trust me
22:23imirkin: but also perhaps building things isn't for you... that's why you're using a binary distro afterall. so you can just stick with what it provides and move on with life
22:24jayhost: Hey hey don't you patrionise me :D
22:25karolherbst: I agree with imirkin
22:25imirkin: i'm actually being serious
22:25karolherbst: me too
22:25jayhost: Something is lost in translation here. Instructions just say make install. I don't know how to get GLXINFO to update
22:26imirkin: jayhost: you have to read *all* the instructions
22:26imirkin: if you've read the page from start to finish, every word on that whole page, then you can come back and ask questions
22:26imirkin: (make that... read and understood)
22:36jayhost: Alright well I imagine you meant the part on Userspace in which case I had just skipped to Mesa
22:37imirkin: yes, starting with userspace
22:37imirkin: you don't have to *follow* all the instructions, but you do have to understand them all and why they're there
22:38jayhost: Now, I'm going to have to switch all my computers to arch because you guys make fun of me.
22:38imirkin: once you do, you can pick and choose what bits of it you want to follow
22:38jayhost: "Oh you're using the Appstore Linux" ;)
22:38imirkin: distro doesn't matter -- irrespective of distro, you shouldn't be overwriting your system-installed stuff
22:38imirkin: unless you plan on never again using your distro's pacakge manager
22:38imirkin: [which is how i used to use slackware back in the day]
22:40jayhost: I actually have just used Debian because It's the stable grandfather distro and my only experience with slackware is puppy linux :D
22:41imirkin: like i said, the exact distro you use doesn't matter
22:41imirkin: you don't have a ton of experience building stuff, so your mistakes are understandable
22:42jayhost: Yeah I'm only ever building games or emulators.
22:45jayhost: I kind of enjoy breaking things though and trying to figure out why it's broke.
22:47jayhost: Traditionally so I'll have to take into account how to do things more modular.
22:50jayhost: Sandboxed or whatever you call it
22:50imirkin: "different prefix"
23:10karolherbst: jayhost: LD_LIBRARY_PATH is your firend
23:11imirkin: and strace too :)
23:11karolherbst: yeah, strace...
23:11karolherbst: but this more to find stupid errors you shouldn't encounter in the beginning :D
23:11karolherbst: but once I had an issue where a include file from /usr/local/include were used and the structs were slightly different...
23:11imirkin: like "why isn't it loading the library i think it should be loading"
23:11karolherbst: a lot of fun debugging this
23:13jayhost: Hmm I had just read an article quite recently called Why LD_Library_path is bad
23:13karolherbst: I should sleep, but somewhat it is too late for that now...
23:14jayhost: But I think the article is about not having your programs depend on it for the user
23:14imirkin: as a user, it's a great tool to have
23:14imirkin: as a distributor of applications, you absolutely can't rely on it
23:15imirkin: karolherbst: yeah, i'm heading off to bed too... and i'm like 6h behind you :)
23:19jayhost: I'm used to just hacking things together. Last night I got Blender 2.49 to run but had to get libpython2.5.so from an archive and cp'ed to the build folder. Unfortunate time waster
23:21jayhost: Yeah haha that's what it wants and now it still tells me python doesn't exist after setting $pythonhome
23:21jayhost: current version of blender I think is 2.69
23:21jayhost: python 2.7
23:23jayhost: I had heard something about redhat supporting 2.5 until 2020
23:26jayhost: new blender is 2.77 oops