00:36 karolherbst: imirkin_: mhh, I can't find a statement for either case
00:37 karolherbst: the only thing the spec is quite precise about is if the same image attached to a fbo is used as a source and the same fbo was bound for drawing
02:18 karolherbst: *sigh*, I'll just run the entire WebGL through valgrind :/
02:29 glisse: anyone knows how the lowerbit of 0x619f04 works ? like if i wanted to set a sys memory address there
02:29 glisse: 1 seems to be for vram
02:30 glisse: so i was guessing 2 for system memory cache coherent
02:31 imirkin: don't know for sure, but perhaps the same enum as in PTE's?
02:31 glisse: yeah that's what i tried
02:31 imirkin: may i inquire as to what you're trying to do?
02:31 glisse: and shifting the dma addr in various 4 increment
02:32 imirkin: also, from your questions, you already have quite an advanced understanding of nvidia board operations...
02:32 glisse: trying to use that to test dma ie can the gpu access main memory
02:32 glisse: right now i am trying on x86 were the gpu works
02:33 imirkin: ok, and so you're feeding the address into 0x1700?
02:33 imirkin: while setting 619f04 to 0 or 2 or whatever?
02:33 imirkin: note that the 8 bit also has to be set
02:34 imirkin: i mean, 0x8, not the 8th bit
02:34 glisse: looking at the bios thing i am not sure how 0x1700 works, i thought that writting addr to 619f04 and than reading at 0x700000 was it
02:35 imirkin: in order to ensure you're using it semi-correctly, try reading/writing vram through that window
02:35 imirkin: so 0x1700 is the base address for accesses at 0x70000000
02:35 imirkin: er, too many 0's
02:36 imirkin: have a look at nvkm/subdev/instmem/nv50.c
02:37 imirkin: (the *_slow methods)
02:37 glisse: yeah that one has many 0 :)
02:45 imirkin: glisse: https://github.com/envytools/envytools/blob/master/rnndb/display/g80_pdisplay.xml#L787
02:46 imirkin: and 619f00
02:47 imirkin: no indication of how it might be used
02:47 imirkin: i think it's a separate mechanism
02:47 imirkin: you really need to use 0x1700 + 0x700000
02:47 karolherbst: imirkin: we more or less use that window in nvafakebios to upload a vbios into vram though
02:48 imirkin: karolherbst: right, but ... it has no connection to the 0x700000 thing
02:48 imirkin: (or does it?)
02:48 karolherbst: it does
02:48 karolherbst: it's the pramin method used
02:48 glisse: what is shr for ?
02:48 glisse: shr=16
02:48 glisse: shift right
02:49 imirkin: karolherbst: yeah, but read nvafakebios -- it reads the address from 619f04 and then writes it into 0x1700
02:49 imirkin: glisse: yes, shr = shift right
02:49 karolherbst: mhh, nvidia uses 0x619f04 to somehow know how mauch vram the GPU has, but that value isn't necessarily set
02:51 glisse: what is ram window ?
02:51 imirkin: dunno
02:51 glisse: like it sounds i should be using ram window rather than rom
02:51 imirkin: you should be using neither
02:51 glisse: :)
02:51 imirkin: what address are you trying to write to?
02:51 imirkin: i.e. have the gpu write (or read)
02:52 glisse: well right now i am trying a page that i dma map
02:52 glisse: on x86
02:52 imirkin: right
02:52 glisse: i am only reading to avoid bad thing
02:52 imirkin: so you have the physical (or dma) address, yes?
02:52 glisse: dma address
02:52 imirkin: crap, lost my place. hold on.
02:53 imirkin: ok
02:54 imirkin: then you write (addr >> 16) | (0x2 << 24) to 0x1700
02:54 imirkin: and then you read from 0x700000 + addr & 0xffff
02:55 imirkin: and if the dma address is higher than 40-bit, you weep
02:56 imirkin: if this is pascal, good chance that's slightly different, since it has 48-bit addresses? dunno.
02:57 glisse: they haven't updated most of this stuff
02:57 glisse: i think they updated them only in volta or turing
02:57 karolherbst: should be volta
02:58 imirkin: oh ok. i kinda stopped caring around kepler, for obvious reasons
02:58 glisse: that works :)
02:58 glisse: thanks
02:58 imirkin: yw :)
02:58 glisse: well now i need to wait my turn to get time on the ppc thing ...
02:59 imirkin: oh. you're testing on x86. which you have in your posession. makes sense.
02:59 imirkin: like the supercomputers of yore...
02:59 glisse: :)
02:59 glisse: x86 is the super computer for kids
03:00 karolherbst: I am sure x86 is one of the platforms where you have _more_ issues the more CPUs you have
03:00 imirkin: having lots of slow cpu's is almost universally worse than one fast one...
03:01 karolherbst: I am sure by default everything gets slower if you have two x86 CPUs instead of one
03:01 karolherbst: identical ones
03:01 glisse: that's amd issue on windows with threadripper
03:01 glisse: on linux in most cases it works ok
03:02 glisse: after all people at spent the last 10yers optimizing for NUMA
03:02 karolherbst: okay, right, because linux usually schedules threads smart enough
03:02 glisse: also memory placement
03:02 karolherbst: and tries make use of caches
03:02 glisse: that matter much more
03:02 glisse: well depends on the workload
03:02 glisse: bandwidth accross socket or chiplet sucks
03:02 karolherbst: memory bandwidth sucks as well
03:02 glisse: half iirc of the bandwidth of your local connected RDIMM
03:03 karolherbst: you are good as long as you hit the L3 cache, which gets harder if you get a second CPU on the board :) or your workload is just crappy
03:04 glisse: try atomic to remote memory ...
03:04 karolherbst: :DD
03:04 karolherbst: fun, I guess?
03:04 glisse: those things are joy to work with
03:04 glisse: some folks consider each socket as an independant computer
03:04 karolherbst: smart thing to do
03:04 karolherbst: solves most of your issues
03:05 karolherbst: because you think different about your application
03:05 karolherbst: the hdckahdkjasdhkasjchnkjasch1!
03:05 karolherbst: damn
03:05 karolherbst: valgrind caught an error
03:05 glisse: yeah, again depends on your workload, some poor smuck have dataset too big for single socket
03:05 karolherbst: imirkin: guess waht happened then
03:05 imirkin: it crashed
03:05 karolherbst: much worse
03:05 imirkin: it hung
03:05 karolherbst: nope, the terminal window closed
03:06 imirkin: ahaha
03:06 karolherbst: and you know, I was smart
03:06 karolherbst: I added the "--noclose" flag
03:06 imirkin: sorry, it's impolite to laugh at another man's pain...
03:06 imirkin: but ... hahahah
03:07 karolherbst: mhh... maybe I should log into a file...
03:07 glisse: https://www.youtube.com/watch?v=kdOPBP9vuZA
03:08 glisse: damm some one made a 10h video of haha and uploaded it to youtube ... https://www.youtube.com/watch?v=2LM0CZZ9Uw8
03:08 glisse: internet bring the best in human
03:08 karolherbst: imirkin: I am sure, if I tell valgrind to log into a file, chromium is smart and restarts the thread and valgrind just overwrites the old log file
03:08 karolherbst: ...
03:08 karolherbst: mhh, log into an fd
03:08 karolherbst: that sounds like what I want
03:08 karolherbst: or a pipe
03:08 karolherbst: mhh, that sounds like a good idea
03:09 karolherbst: uhm... fifo I meant
03:11 imirkin: oh, it's the stupid thing where chrome restarts the thing? very annoying
03:11 karolherbst: okay, next try
03:12 karolherbst: yeah...
03:12 imirkin: you can attach gdb to the valgrind
03:12 imirkin: and have it pause on error
03:12 karolherbst: I rather not
03:12 karolherbst: gdb + valgrind brings back bad memories
03:12 karolherbst: I just let valgrind write into a fifo and have a cat | tee somewhere else
03:12 karolherbst: should work fine as well
03:13 karolherbst: mhh, allthough right, might be easier to debug with gdb, but I hope valgrinds output is good enough
03:16 imirkin: well, you can just continue in gdb as necessary
03:16 karolherbst: right, but I never had luck reproducing just issues when I used gdb + valgrind at the same time
03:16 imirkin: yeah, dunno
03:17 karolherbst: maybe it would work in that case, dunno
03:18 karolherbst: imirkin: or those GLES3 CTS crashes, never happend when I ran the entire CTS within gdb :/ stuff like that is just annoying
03:19 imirkin: quite
03:23 glisse: when a program crash you can have the kernel dump the program state in /var/crash or something like that
03:23 glisse: then you can run gdb after the fact
03:23 glisse: forgot how it all works as it tends to be distro specific
03:29 imirkin: glisse: btw, it occurs to me ... this is a pascal board, right?
03:29 imirkin: how is the option rom execution handled on it?
03:29 imirkin: [on ppc]
03:30 glisse: it is pascal, x86 gpu on a ppc, i don't think anything get executed
03:30 glisse: the bootload is just a linux kernel
03:30 glisse: bootloader
03:30 glisse: that kexec your kernel
03:30 imirkin: ok... i don't think that'll work with the firmware loading mechanism
03:30 imirkin: iirc it relies on there already being something there
03:30 imirkin: not sure.
03:31 imirkin: although ... hm. if that were the case, it wouldn't work on resume, but it does.
03:31 imirkin: so perhaps i'm just mistaken.
03:34 imirkin: ben would know for sure
03:59 maxthecat_: when I rmmod nouveau, I got rmmod: ERROR: Module nouveau is in use.
03:59 maxthecat_: so I follow the instructions in https://nouveau.freedesktop.org/wiki/KernelModeSetting/, stop lightdm service, echo 0 > /sys/class/vtconsole/vtcon1/bind, vtcon1 is frame buffer device, then my system stops working.
03:59 maxthecat_: Can anybody help me fix it? I use Linux 4.4 . Thanks.
04:00 karolherbst: imirkin: https://gist.githubusercontent.com/karolherbst/3fa9d15e0a7f146e8d265c70cc889f9f/raw/1426aa59a94d136d84509d61acbfb6963dfb8607/gistfile1.txt
04:02 karolherbst: looks like user after free
04:03 karolherbst: somehow looks like fallout from my mt fixes to be hones
04:03 karolherbst: t
04:46 imirkin: maxthecat_: please elaborate on "stops working"
07:22 maxthecat_: imirkin: After entering 'echo 0 > /sys/class/vtconsole/vtcon1/bind', I was unable to enter commands or switching terminal. have to reboot.
07:57 mtf8: o/
08:00 mtf8: so I've got my dual-dvi GeForce 610 working nicely using the free nouveau driver and I have not dl'd, extracted, and placed the non-free firmware on my disk under /lib/firmware/nouveau. I'm trying to understand if I care...
13:36 karolherbst: interesting, it has nothing to do with my mt fixes
14:16 karolherbst: imirkin: nice.. I found an application which causes a hw channel kill in less than a minute :)
15:03 karolherbst: imirkin: okay, I think I know what the cause of the memory corruption is: at some point we resize the text area, but the pushbuffer still has references to it. With bad luck, we deleted it, but the internal list still has the pointer to it (pushbuf_flush frees, pushbuf_validates accesses)
15:04 karolherbst: and this happens inside the same thread
15:06 karolherbst: mhh, seems like we don't del bos with a refcnt of != 0, so maybe we just forget to take a ref somewhere
15:10 karolherbst: yay
15:10 karolherbst: I made the initial text size 1 << 15 instead of 19, now it crashed in under a minute :)
15:12 karolherbst: mhh, but there are like 40 active contexts... maybe it is indeed mt related?, wondering
15:14 karolherbst: also, with all the fixes, GLES3 deqp: Failed: 4/42653 (0.0%)
16:04 imirkin: karolherbst: hmmm ... the codesize thing is tricky. iirc i ran into that bug and already fixed it :)
16:04 imirkin: er, code page
16:04 karolherbst: imirkin: ahh, so you have a patch but it isn't merged yet?
16:05 imirkin: no, pushed ages ago
16:05 karolherbst: mhh, seems like there are more issues :)
16:05 imirkin: adcd241b563f44b2e3e92f5d840e2f617bc25836
16:06 karolherbst: mhh, I guess there is more to it
16:06 imirkin: i wonder if you need a nouveau_pushbuf_validate in there
16:06 imirkin: but that did fix the issue i was having
16:06 imirkin: which was with bindless + dirt showdown or whatever
16:07 karolherbst: yeah.. I mean I only found that one through chromium running the WebGL cts for over an hour
16:07 imirkin: iirc skeggsb and i decided that this was enough at the time though
16:07 karolherbst: there is some weird stuff going on though
16:07 imirkin: so perhaps something else odd
16:07 imirkin: the way libdrm works is very confusing.
16:07 imirkin: which is one of the reasons i want to kill it off
16:07 karolherbst: there are tons of channel creations and destroys
16:07 karolherbst: uhm
16:07 karolherbst: context
16:09 karolherbst: but that shouldn't really matter as the pushbuf is used by all contexts
16:10 karolherbst: imirkin: after reading some of the code today, it seemed like we could make the libdrm much much simplier if we just assume one bo/pusbuf/whatever is only ever used in one thread and just simplify things towards that (or well, reimplement the API or whatever into a second version of something)
16:37 imirkin: karolherbst: ideally i'd like to import the replacement into mesa
16:37 imirkin: since it's all very tightly integrated anyways
16:38 imirkin: libdrm_nouveau's API is appropriate for much simpler use-cases like the one in the ddx
16:46 imirkin: airlied: any clue what this "lock vga" stuff is about? https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/vga.c#L127
17:21 karolherbst: imirkin: so, it seem like that bo gets deleted on the next flush, but it's still in the bctx->pending list
17:21 imirkin: coz it's ref'd
17:21 imirkin: i.e. pushbuf_refn
17:21 karolherbst: well, a nouveau_bufref is in the pending list with a reference to it
17:22 imirkin: er, hm. right.
17:22 imirkin: we have a bufctx bin for all that stuff
17:22 imirkin: do we not clear it out / remove that one from it?
17:22 imirkin: that'd be bad.
17:23 karolherbst: you mean the reference to the text bo?
17:23 imirkin: no
17:23 imirkin: er, yes
17:23 imirkin: something
17:23 imirkin: hold on
17:24 imirkin: ok, so right after we do
17:24 imirkin: nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEXT);
17:25 imirkin: and dump the new text bo in
17:26 imirkin: so i think the current logic should work ok...
17:26 imirkin: at least so far as i understand it.
17:26 karolherbst: I don't think the problem is that we don't keep a reference, we just never unref the old bo
17:27 imirkin: why not
17:33 karolherbst: ohh, no, you are right. The bo gets dedleted because it's refcnt is 0, but it still seems to be used somewhere
17:33 karolherbst: or uhm, at least y statement wasn't correct
17:34 imirkin: i wonder if we need to a pushbuf_validate to go with the PUSH_REFN
17:34 imirkin: before the bo delete
17:34 karolherbst: yeah, maybe
17:35 imirkin: i'm gonna go play with ppc for a bit. good luck :)
17:36 karolherbst: interesting
17:37 karolherbst: imirkin: doing a pushbuf_validate right after the PUSH_REFN deletes the bo as well :)
17:39 imirkin: ok, we have a work thing
17:39 imirkin: fence_work thing, rather
17:39 imirkin: that allows you to delay such things
17:45 karolherbst: okay... the bo is refed _after_ it gets deleted
17:46 karolherbst: in nvc0_blit
17:46 karolherbst: nvc0_add_resident
17:48 karolherbst: nv50_miptree(pipe_blit_info.src.resource)->base.bo is the text bo
17:48 karolherbst: or at least the address is the same
17:55 imirkin: that can very easily happen
17:55 imirkin: you free() and then malloc(), you get the same address
17:59 karolherbst: only difference, there was no new bo created with the same address
18:00 karolherbst: ohh wait, got my printfs wrong again
18:03 karolherbst: okay, I can confirm there is no new bo with the same address until the corruption appears
18:05 karolherbst: or... not always
18:14 imirkin: crap. i think my g5 has died =/
18:15 karolherbst: :(
18:17 karolherbst: imirkin: how to unref a bo from a bufctx?
18:17 imirkin: no clue
18:18 imirkin: i mean bufctx_reset() for the most part
18:19 karolherbst: nvc0->bufctx_3d keeps the reference
18:19 karolherbst: to the old text bo
18:20 kisak: karolherbst: that sandybridge / fermi 525M the other day ... so far the 525M with nouveau is acting subjectively better than the intel chip with the few games I tried to run. marginally better framerate and less/no rendering artifacts vs intel
18:21 karolherbst: kisak: huh? how's that possible
18:21 karolherbst: the intel driver ain't that bad
18:22 karolherbst: uhm
18:22 karolherbst: kisak: sure it uses the intel driver?
18:22 karolherbst: not that it does like.. software rendering
18:22 kisak: sure, it's using the gpu in both cases
18:22 karolherbst: how sure?
18:22 kisak: very
18:22 imirkin: kisak: SNB is a pretty shitty chip
18:23 imirkin: (in terms of graphics, cpu is fine)
18:23 karolherbst: imirkin: but compared to a 525m with default clocks?
18:23 kisak: glxinfo vs DRI_PRIME=1 glxinfo sure
18:23 imirkin: well, more features could be getting used with the fermi
18:23 imirkin: kisak: if you want, there's a branch for fermi reclocking
18:23 karolherbst: it might be that the intel chip is busy with the desktop though
18:23 imirkin: however it didn't work for me
18:24 imirkin: but i had a display attached, with increases the complications
18:24 karolherbst: there are some issues with higher clocks on fermi
18:24 imirkin: kisak: https://github.com/skeggsb/nouveau/tree/devel-clk
18:24 imirkin: karolherbst: i used precisely the same GPU as skeggsb did for developing :)
18:24 imirkin: same Quadro 400 board. except apparently somehow different.
18:25 karolherbst: imirkin: there are magic clock ranges you need to do things differently, might be that you had slightly higher clocks or something :)
18:25 imirkin: karolherbst: in theory it's the same board, should have the same everything
18:25 imirkin: i don't think we ever compared vbios's precisely though
18:26 karolherbst: in practise you also have that weirdo speedo value which might affect the highect clock selected, etc...
18:26 karolherbst: it's already a thing on fermi
18:26 karolherbst: just a question whether that was tested before or after my voltage patches landded
18:26 karolherbst: anyway, htere are always odd things going on
18:27 kisak: karolherbst: main issue with the sandybridge was broken alpha transparency on some textures with wined3d9->ogl which are fine on the fermi. not really expecting decent perf anywhere anyway
18:27 karolherbst: ohhh
18:27 karolherbst: wined3d9
18:27 karolherbst: right
18:27 karolherbst: yeah, intel can't do that
18:27 karolherbst: I mean, gallium nine
18:27 karolherbst: so nouveau uses gallium nine, which is a totally different path to begin with :)
18:27 karolherbst: and usually faster
18:28 imirkin: if you have the nine stuff set up
18:28 kisak: sandybridge also somehow has input lag with a steam controller on a native game that feels fine with nouveau
18:29 imirkin: well, enjoy =]
18:29 kisak: I don't have gallium nine setup yet
18:29 imirkin: if you do run into issues, make an apitrace and report them
18:29 imirkin: in general, nouveau's fairly standards-conforming
18:32 kisak: I was trying to run opengl deqp tests yesterday, but eventually gave up from segfaults for sandybridge and kernel lockups with fermi, testing ended with not being able to run mustpass lists from an unexpected int returned in a transform feedback test
18:32 kisak: ^just to play around with the test suite
18:33 karolherbst: imirkin: ohh right, GLES3 is fail free (except those preprocessor tests) :)
18:33 imirkin: kisak: yeah, those tests do weird things
18:33 karolherbst: the deqp tests
18:33 imirkin: for regular software, it's pretty good though
20:48 imirkin: rhyskidd: do you have push access to xf86-video-nouveau?
20:48 rhyskidd: i don't think so,
20:48 rhyskidd: i have to a bunch of other mesa and xorg stuff though
20:48 imirkin: k
20:49 rhyskidd: am i right that xf86-video-nouveau never moved to gitlab fdo?
20:49 imirkin: dunno
20:50 kisak: looks like it's not on gitlab
20:51 imirkin: rhyskidd: what tree is that "radeon" commit in?
20:55 rhyskidd: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/d670c5c9851b4eff21c845d26c7d7e4eb5ee0fa9
20:57 imirkin: rhyskidd: the radeon code just stops calling that function entirely
21:02 rhyskidd: but they call it at least once where xf86_reload_cursors was called, within their gamma fuction -- nouveau just never does that second one
21:02 rhyskidd: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/blame/master/src/drmmode_display.c#L1342
21:03 imirkin: ah
21:03 imirkin: have you tested it?
21:04 rhyskidd: only on a tesla
21:04 imirkin: did it work? =]
21:05 rhyskidd: yes
21:05 imirkin: ok, i'll try it out locally as well
21:05 imirkin: assuming all goes well, will push it out
21:05 imirkin: we need to cut a new release too
21:06 rhyskidd: i'm looking at the other two new warnings that were introduced building against xorg-server 1.20, they look legit
21:12 imirkin: ok
21:27 karolherbst: imirkin: okay... I think in order to do it correctly, we would need to validate the pushbuffer with each bufctx_3d and bufctx_cp attached from each context
21:28 karolherbst: well, nouveau_pushbu_validdate moves all items from the pending to the current list and a flush should do the trick then
22:00 karolherbst: imirkin: do you think we need those "BCTX_REFN_bo(nvc0->bufctx_3d, 3D_TEXT, flags, screen->text); BCTX_REFN_bo(nvc0->bufctx_cp, 3D_TEXT, flags, screen->text);" calls?
22:00 karolherbst: because removing those solves the issue
22:02 karolherbst: mhh, but then we never ref the text bo :/
22:47 karolherbst: but nouveau + 970m runs quite well in general :)
23:14 imirkin: karolherbst: until those buffers get evicted, that works fine
23:14 imirkin: rhyskidd: send patches to list if you want them reviewed by me
23:15 karolherbst: imirkin: what are you refering to precisely?
23:16 imirkin: karolherbst: well, the whole reason why we do this buffer tracking stuff, is so that ttm can ensure that buffers are in vram/gart
23:16 imirkin: while the code is executing
23:16 imirkin: er, while the commands are executing
23:16 imirkin: i.e. until a fence is reached
23:23 karolherbst: imirkin: ohh btw, we might have a nice solution for that pid/name issue on dead channels. We just copy the name once the channel was created
23:24 imirkin: yeah, i had a temp patch to do that
23:24 imirkin: passing it through everywhere is a _giant_ pain
23:25 karolherbst: imirkin: ohh, cool. I've discussed this with skeggsb and I think this was his preferred solution as well
23:25 karolherbst: or at least one simple trick we can do
23:25 karolherbst: and which would ease our pain quite a lot
23:25 karolherbst: imirkin: regarding the text bo, right. The thing is just, that we have several objects which store the reference to that bo and I don't really see a way on how to manage that correctly. Maybe we shouldn't add those to the bufctx on context creation time but just ref those whenever we execute that shader and basically track it like we do for other resources?
23:27 imirkin: that's the whole purpose of a bufctx
23:27 imirkin: every time that you kick, you get a new bo list
23:27 imirkin: the bufctx allows you to stick things onto that bo list every time
23:27 karolherbst: okay, sure, but now we have the issue that we have like 40 contexts
23:27 karolherbst: and each of those refs the text bo twice
23:28 karolherbst: and apperantly even after a kick, at least one of those still has the reference to the old text bo
23:28 karolherbst: so at least it doesn't seem to work all that great for shared resources
23:29 imirkin: hm, interesting point --
23:29 imirkin: the text bo is a screen resource
23:30 imirkin: but we're managing it in a per-context bufctx
23:30 imirkin: that's doomed to fail
23:30 imirkin: very interesting and relevant point.
23:30 karolherbst: mhh, with my apporach to get each context its pushbuf we could eventually just ref the old bo on each bufctx of each context :/
23:30 karolherbst: dunno if that would work out
23:31 karolherbst: will add locking pain at least
23:31 imirkin: so the reason that the text is screen-wide is that it introduces a stall to try to just change it
23:32 karolherbst: currently the text bo is 512 kB by default... we could just increase it an never evict it .... :/
23:32 karolherbst: uhm, resize
23:32 karolherbst: but.. we have the same issue for the tls buffer as well I guess
23:32 karolherbst: just unlikely that this will be a problem
23:33 imirkin: this whole resizing is a "new" thing
23:33 imirkin: the original logic had it at a fixed size
23:33 imirkin: we added it to thread the needle between taking up too much vram for each program that touches GL and being able to have a large text segment for games
23:34 karolherbst: maybe we could have it 2MB, but up to 0.5% of vram
23:34 karolherbst: or something
23:34 karolherbst: still fixed
23:34 karolherbst: worst thing I noticed was bioshock infinite which caused 3 resizes
23:34 karolherbst: would be 4MB
23:35 imirkin: so ... remember that like some earlier tesla boards had 128mb
23:35 imirkin: i realize this is nvc0 code, which could have different defaults for fermi+
23:35 karolherbst: right
23:35 karolherbst: or we just say 0.5Mb up to 0.5%
23:35 karolherbst: and if that's not enough, the workload is probably too heavy anyway
23:36 karolherbst: 0.5MB is the current default size afaik
23:36 karolherbst: size is 1 << 19 for nouveau_bo_new, whatever that means in the end
23:40 karolherbst: mhh, but that is annoying the more OpenGL applications you have running
23:48 karolherbst: those CTXSW_TIMEOUTs though :/
23:49 karolherbst: if there would be _any_ way to debug those
23:50 karolherbst:should really work on the shader trap handler at some point, could be useful