00:00 pmoreau: Besides working on SPIR-V, I have done nothing in Mesa.
00:00 karolherbst: okay
00:00 karolherbst: I always thought so though
00:04 karolherbst: CHSW_ERROR?
00:05 calim: and no your box doesn't look odd, why
00:05 karolherbst: mhhh
00:05 karolherbst: there is an odd crash with HitmanPro on nouveau
00:05 karolherbst: and it doesn't seem mt related
00:08 lotus: Hey, how can I get the BusID for the xorg conf to assign the nouveau driver to a device?
00:08 lotus: lspci looks promising, but nothing stands out as being "BusID"
00:11 pmoreau: Wouldn’t that be the XY:WZ?
00:13 pmoreau: Looking at the man page of lspci, "Slot The name of the slot where the device resides ([domain:]bus:device.function). This tag is always the first in a record.", so XY would be the BusID it seems
00:17 lotus: what is XY?
00:18 lotus: i.e. 04:00.0
00:18 lotus: PCI:04:0:0?
00:20 pmoreau: So, 04 in your case; 00 would be the device id, and 0 the function id.
00:24 imirkin: karolherbst: 901120 is a perfectly fine size. mlankhorst might be right, it's returning MAP_FAILED. which would be odd.
00:25 imirkin: it's a 64-bit app, so address space exhaustion seems unlikely
00:27 calim: add lots of prints and see what's happening
00:40 dboyan_: imirkin: I never thought that histogram program would trigger so many bugs
00:40 dboyan_: I found a bug within the blob in a previous version
00:40 dboyan_: This version contained a workaround for that
00:41 imirkin: hehe, well, it tests out various data flow paths
00:42 pmoreau: What is usually done in Mesa for propagating back error messages in the C-API? The caller allocates some memory or sends a null pointer if it doesn’t care about the message, or the callee does the memory allocation (does the caller signals whether it wants the error message?), or just an error code is returned?
00:42 imirkin: i'm not sure what's broken here - i think it might even be the atomics. that'd be sad.
00:42 imirkin: pmoreau: most gl* functions don't return. you just call _mesa_error() and return;
00:44 dboyan_: btw, I think I'm going to apply for gsoc, most probably for instruction scheduling
00:44 imirkin: i hope you realize that that's a VERY tough project
00:45 dboyan_: I do, and I think I've got to learn a lot in the process
00:47 pmoreau: imirkin: Hum, ok. I wanted to return messages if the SPIR-V binary was not correctly formed, with some details about what was wrong. I was initially outputting all of that through debug_printf. _mesa_error() looks interesting, if it wasn’t tied to OpenGL. :-D
00:48 imirkin: pmoreau: well it's tied to the API that the user is calling :)
00:49 pmoreau: Don’t think it would work if I wasn’t calling it from the OpenCL API, as it takes an OpenGL context as argument
00:49 pmoreau: s/wasn't/was
00:50 imirkin: right
00:50 imirkin: for opencl you need to do it the opencl way :)
00:51 pmoreau: :-D
00:51 imirkin: and it needs to be in the opencl handling code
00:51 imirkin: the inner logic like gallium should return errors that those handlers convert into "the api way"
00:52 pmoreau: I should have been clearer: I am writing some code that could be used by OpenCL logic and OpenGL logic, and I would like to give those back some error message (which they could discard if they want to).
00:53 imirkin: ok... *thumbs up* ... not sure what you're looking for :p
00:55 pmoreau: So, if there are other such pieces of code, who is responsible for allocating the memory: is it usually the caller that allocates a fix amount, or the callee which allocates whatever is needed?
00:55 imirkin: i don't think there's a standard
00:56 pmoreau: Ok, I’ll just pick something and see what comes up during the reviewing process.
00:58 ystreet00: glib has GError
00:59 ystreet00: which is callee allocates and caller frees when necessary
01:02 pmoreau: Sounds reasonnable
01:02 calim: error handling just makes code uglier ^^
01:03 calim: besides, whichever code produced you that malformed binary isn't going to fix itself on the fly :3
01:05 pmoreau: Of course! :-D
01:06 pmoreau: But knowing why the API rejected the binary, can be helpful. Though, mostly to the dev rather than the user, that is true.
01:07 dboyan_: imirkin: I'm just checking if I'm competent enough, and also if there are potential mentors out here.
01:07 calim: the question is what's gonna happen with the error report if you propagate it, if it'll only end up being printed anyway you might as well do it on the spot I guess ...
01:09 pmoreau: True enough
01:13 calim: marveling at error messages is fun though
01:36 mooch2: imirkin: i'm curious, how much do you have to lie to get g80 to gl 3.3?
01:39 dboyan_: mooch2: Haven't used g80 card myself, but is it necessary to lie to get gl 3.3? Or does noveau really lie?
01:39 dboyan_: *nouveau
01:39 mooch2: i know the blob lies A LOT to get riva tnt to gl 1.5
01:39 mooch2: the hardware doesn't even support 3d textures, so it barely works for gl 1.2
01:40 dboyan_: That's different for g80 I guess
01:40 mooch2: yeah
01:40 mooch2: they didn't add 3d textures till NV3x
01:43 mooch2: nouveau only supports up to gl 1.2 on riva tnt
02:22 imirkin: mooch2: only a tiny bit... iirc the only thing not supported is seamless cubemap textures. that goes on until the DX10.1 cards (GT215+)
02:22 imirkin: (or does G200 also have it? i forget)
02:22 mooch2: ah
02:22 mooch2: interesting
02:22 mooch2: what's the most lying that the blobs do, anyway?
02:22 imirkin: nv30 getting GL2.0 i assume
02:23 mooch2: also, why doesn't the blob support vulkan on fermi?
02:23 mooch2: i know fermi supports gl 4.5
02:23 imirkin: coz fermi isn't bindless, and it'd be more effort for them
02:23 mooch2: ah
02:23 imirkin: based on some handwaving, G80 should be able to do vulkan
02:24 mooch2: lol, that's actually kinda funny
02:24 mooch2: what about nv4x?
02:24 imirkin: no compute support, and no ton of other things
02:24 mooch2: sure they couldn't do compute, but i'm not sure that's mandatory
02:24 imirkin: it is.
02:24 mooch2: oh
02:24 imirkin: gtg
02:24 mooch2: k bye
03:08 imirkin: also fwiw blob driver doesn't *lie*, it just implements the missing bits in software
03:08 imirkin: like i assume using 3d textures on pre-nv30, that just got you on the swrast path
03:23 Horizon_Brave: hey everyone
03:24 Horizon_Brave: happy saturdays... Samurai Jack returns...
03:25 gnarface: gotta get back...
03:26 Horizon_Brave: back to the future...
03:26 Horizon_Brave: fuuuu
03:26 gnarface: no, it goes: "Gotta get back, back to the past, Samurai Jack!"
03:27 Horizon_Brave: Watcha!
03:27 gnarface: hehe
03:50 dboyan_: imirkin: While thinking about implementing binary shader cache for nouveau, I wonder where the code should reside, codegen or nvc0/nv50 or somewhere else.
03:50 imirkin: nv50/nvc0.
03:51 imirkin: there are various bits in the nv50/nvc0 programs that can cause recompilation of the codegen stuff
03:51 imirkin: kinda like a shader key, but not really
03:52 dboyan_: but there are something like optimisation level in codegen that should also be taken into account
03:52 dboyan_: karolherbst mentioned that yesterday
03:53 imirkin: yeah, but those levels are configured by nv50_program/nvc0_program ;)
03:53 imirkin: src/gallium/drivers/nouveau/nv50/nv50_program.c: info->optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
03:54 dboyan_: that makes sense
03:59 dboyan_: I think I'll try it in nvc0 first then. It's not a trivial work like the radeonsi one, since radeonsi already had an in-memory cache and various binary formats in place.
04:04 imirkin: the code is available inside the nvc0_program structure
04:04 imirkin: in cpu memory
04:04 imirkin: you have to package it up along with all the relocation/fixup information
04:04 imirkin: which we apply at code upload time
04:09 mooch: NOUVEAU VULKAN DRIVER WHEN
04:09 mooch: jk
04:12 Horizon_Brave: Hey, does the AMD Radeon driver have a similiar community of open source devs like Nouveau has here?
04:15 imirkin: in #radeon
04:21 Horizon_Brave: lol...it seems like there would be a rivialry between you guys....do you guys collaborate or talk and help each other?
04:21 imirkin: not aware of any rivalry
04:22 imirkin: we all see each other's work going into the repo, and answer questions about it when asked. tons of shared features and whatnot too.
04:25 gnarface: Horizon_Brave: intel, amd, and nouveau drivers are all co-dependent upon Mesa for OpenGL rendering. nvidia is the odd-man-out in this situation. everyone else very much is pooling efforts to get Linux working.
04:26 gnarface: (that this requires Mesa is somewhat of a joke if you know a bit about Mesa's origin story, but hey, that's the sad world we live in)
04:28 Horizon_Brave: lol ah..why do I feel like it's a long twisted story in there...?
04:29 Horizon_Brave: how is nVidia such a thorn in everyone's side in the FOSS community... jeez really paints them in a bad light lol...
04:29 Horizon_Brave: I sort of regret supporting them by buying the geforce 1050
04:30 gnarface: most people integrate their drivers into the linux kernel by checking for available interfaces and adjusting their own software accordingly. nvidia's integration process is more like trying to integrate a commercial cruiseliner with an iceberg.
04:32 Horizon_Brave: lol
04:33 Horizon_Brave: lol wait...isn't that a sort of one sided battle?
04:33 gnarface: yea basically they just rammed it at full speed and expected something to give
04:33 Horizon_Brave: I think the Titantic tried that once..
04:33 gnarface: the resulting impact on linux stability and security was figuratively quite similar
04:34 Horizon_Brave: http://www.pcworld.com/article/2911459/why-nvidia-graphics-cards-are-the-worst-for-open-source-but-the-best-for-linux-gaming.html
04:34 Horizon_Brave: reading this
04:34 gnarface: yea, and the worst part is despite it all, they still have the fastest opengl drivers
04:34 gnarface: (if they didn't, they'd have to actually play by the rules, which is why we're all not-so-secretly cheering on AMD)
04:35 Horizon_Brave: and that's because they keep there private binary stuff right?
04:35 gnarface: well, yes, if they didn't do that then nouveau could be completed the "right way" easily and their own binary gunk would be a non-issue
04:36 Horizon_Brave: like, what makes their drivers so much better? in theory, because AMD and intel, release some of their code atleast, shouldn't that, if anything make them better? more people looking and modifying it?
04:36 gnarface: it's not just that they keep their stuff private you see, it's that they keep it private *and* also obstruct upstream kernel development by refusing to change the way the driver works to use the same interfaces that everyone (amd, and intel) use
04:38 Horizon_Brave: it just strikes me as odd, that open sourced code from intel, and amd, would be inferior to nvidia's even though, in theory they have a much much wider range of people looking at it, and helping
04:38 gnarface: these things take time
04:40 gnarface: nvidia's driver has been in constant development for decades, and there is basically just one core bit that is used across all supported cards for all supported operating systems. AMD and Intel have scrapped their entire code base and started over so many times it's just not a fair comparison. they have a lot more work ahead of them, and while they're doing it they're contributing to mesa and the kernel a lot more
04:40 gnarface: than nvidia does
04:41 Horizon_Brave: ahh
04:42 gnarface: AMD and Intel have made serious strides and helped Mesa alot in the process though, just over the last 2 years. for the first time in a long time, it seems like they actually care about performance on linux. so that's also an important recent change, compared to historical behavior
04:42 Horizon_Brave: nvidia is just pooling all of their resources into their own device stack. While intel and amd have to not only worry about their own cards, but helping to evolve the linux graphics stack..(which is what mesa is I'm assuming)
04:42 gnarface: yea, bascially
04:42 gnarface: there's more to it than just mesa, but mesa is the key opengl part
04:43 Horizon_Brave: nividia gets to blissfully ignore that part.... speaking of which... are you guys having a rough time adopting to the wayland architecture, from the older X.org?
04:43 gnarface: nvidia distributes their own opengl libraries in place of mesa, which literally everyting else uses
04:43 gnarface: i can't speak as a nouveau developer about wayland. dunno about it.
04:44 gnarface: last i heard though, nvidia refused to cooperate with wayland, so nouveau is your only hope there, for now
04:44 gnarface: (i wouldn't be surprised if it's also painful to get working though)
04:44 Horizon_Brave: what? nvidia reason to play ball with an opensource project? surely you jest
04:45 gnarface: they're friends with Microsoft
04:45 gnarface: it's personal to them
04:48 gnarface: but as we've seen with Valve's change in posture with regards to Linux, that friendship is not necessarily iron-clad
04:48 gnarface: anyway, dinner time for me
04:48 gnarface: later on
04:51 Horizon_Brave: thanks for your help each night of questions from me!
04:51 Horizon_Brave: enjoy mate
08:55 airlied: imirkin: i think sli bus is possibly a video bus like dvo
10:04 karolherbst: imirkin: all assignments to tx->map have sane values, so it should be something non obvious, will folow that MAP_FAILED path though. I saw that the value is changed somewhere else as well
12:42 tarragon: mm... just when I got excited to contribute to this project somebody races ahead and does it --> http://phoronix.com/scan.php?page=news_item&px=Nouveau-TGSI-Cache-Patch
12:42 tarragon: karolherbst: can you help me set up nouveau SDK?
12:42 tarragon: I want to try helping with vulkan and opencl
12:43 pmoreau: I wouldn’t be interested in help on OpenCL.
12:43 tarragon: why doesn't opencl work? where should I start? which files ? etc..
12:43 tarragon: pmoreau: I am --> darktable, tesseract
12:43 tarragon: pmoreau: waht you said makes no sense.
12:44 pmoreau: I am working on OpenCL, and if you are willing to help, that would be nice :-)
12:45 pmoreau: Ah, s/interested/uninterested
12:45 tarragon: pmoreau: wait, are or you aren't? stop writing with forked tongue
12:46 pmoreau: It was supposed to be a double negation, but i missed the second negation: I wouldn’t be uninterested
12:46 pmoreau: Or without the double negation, I would be interested
12:47 tarragon: in other words is that a yes or no?\
12:48 pmoreau: I have been working on OpenCL for some time, and I accept anyone willing to help. Clearer?
12:48 tarragon: yeah
12:49 tarragon:wonders what karol is up to.
12:49 pmoreau: good :-)
12:49 tarragon: pmoreau: what are the step for me to help you out?
12:49 pmoreau: So, the main problem in getting to run OpenCL kernels on Nouveau, is getting the kernel code in some format that Nouveau can understand
12:50 pmoreau: To achieve that, I have been writing a translation unit from SPIR-V to the intermediate representation used by Nouveau
12:50 tarragon: pmoreau: exactly the message I got.
12:51 tarragon: pmoreau: do you have some docs to read and files and repositories?
12:51 pmoreau: It now supports a few things, but more needs to be translated.
12:51 pmoreau: Sure
12:51 pmoreau: One sec
12:51 pmoreau: SPIR-V specification: https://www.khronos.org/registry/spir-v/specs/1.1/SPIRV.html
12:52 tarragon: pmoreau: and the nouveau related docs?
12:52 pmoreau: My current work: https://phabricator.pmoreau.org/diffusion/MESA/repository/clover_binary/, branch clover_binary is the most up-to-date one; clover, the OpenCL API implementation in Mesa, also needs some additional support.
12:53 tarragon: pmoreau: lemme read those docs and come back.
12:53 pmoreau: There is no real documentation on how Nouveau’s intermediate representation looks like.
12:54 tarragon: mm.. or any nouveau relevant part.
12:54 pmoreau: Not really either… :-/
12:56 pmoreau: Most of the work for the Nouveau part happens in: https://phabricator.pmoreau.org/diffusion/MESA/browse/clover_binary/src/gallium/drivers/nouveau/codegen/nv50_ir_from_spirv.cpp (and yes, that code needs some serious cleaning)
12:57 tarragon: pmoreau: is that your site? is hooked up to fiber landline or old copper?
12:58 pmoreau: It is my site, but I rent the server. Not sure how it is hooked up
12:58 tarragon: ah ok, because it didn'd load instantly
12:58 tarragon: like youtube and google
13:00 pmoreau: Depends which page you load: the main page of Phabricator is <1 sec for me, but the nv50_ir_from_spirv.cpp takes about 20 sec.
13:00 tarragon: true
13:01 tarragon: pmoreau: ok lemme read that khronos doc first
13:02 pmoreau: Sounds good.
13:02 pmoreau: Probably starts by having a quick look at sections 1.9, 2.3 and 2.4
13:03 pmoreau: There is also the whitepaper which could be interesting for a first read: https://www.khronos.org/registry/spir-v/papers/WhitePaper.html
13:03 tarragon: thanks
13:04 pmoreau: bbiab
13:53 RSpliet: oh wow, I never noticed Gnome Shell has a right-click menu item for programs called "launch using dedicated graphics card"
13:58 karolherbst: I want to fix nouveau to get the games running :(
14:04 tarragon: karolherbst: which one fails?
14:04 tarragon: Metal Gear Peace Walker on ppspp emu killed noveau always on the same spot :(
14:08 karolherbst: RSpliet, mupuf, pmoreau: I want to discuss with skeggsb to move the nouveau repository somewhere else (most likely to the envytools user, but maybe we should create a nouveau one?) I would like to add some kind of CI on top of it, which we could even mix with auto generation of new Live CDs or things like that. Especially, because Linus is on to us for producing crappy stuff (drm in general). So we either really
14:08 karolherbst: want to push into linux-next before or have our own CI, which we can actively manage or so
14:08 mupuf: sounds good!
14:08 karolherbst: maybe we will indeed do our merge request without drm-next first as Linus suggested as well
14:08 karolherbst: we will see
14:09 karolherbst: but anyway, having our own CI with build testing should be a good first step
14:09 RSpliet: karolherbst: you mean the kernel sources? is there criticism on nouveau in particular or on DRM as a whole only?
14:09 karolherbst: RSpliet: DRM + Linus said, he would like to have splitted DRM merge requests in the future
14:10 karolherbst: I have it basically ready, just need to roll it out somehow
14:10 RSpliet: right, but that still implies going through drm-next, it'll just no longer be a big fat aggregate to push for him
14:10 karolherbst: I can change it
14:10 karolherbst: currently my travis script depends on drm-next
14:10 karolherbst: but our code base does as well
14:11 karolherbst: (it parses the last "drm-next" merge commit out of the nouveau tree and checks this kernel tree out)
14:11 karolherbst: and then it compiles with various configuration combinations
14:11 RSpliet: the other point to make is, what is moving nouveau to a different source going to bring you? Is CI impossible in it's current form (answer is likely no, but less convenient. Can we make it more convenient?)
14:11 karolherbst: RSpliet: currently nouveau is on skeggsb private github account
14:11 karolherbst: this makes things, inconvinient, because only he could configure it
14:11 karolherbst: afaik
14:11 karolherbst: maybe he can allow others to configure the repository
14:11 karolherbst: not sure
14:12 RSpliet: it's what we did with envytools, non?
14:12 RSpliet: anyway, skeggsb is on holiday for another week, so have a think about the possibilities and goals ;-)
14:12 karolherbst: envytools is a "coorperation" account so to speak, yes
14:13 karolherbst: github reworked the entire cooperation handling, so I have to play around with it before that anyway
14:13 karolherbst: but you can give different members different access rights
14:13 karolherbst: like one group can push, the other can only work through issues.. etc...
14:15 karolherbst: pmoreau: travis can also do cron jobs. aka we could regenerate a new live image regardless if there was any new pushes or so
14:16 karolherbst: but I need to talk with skeggsb with that anyway before doing anything. Just wanted to know if you are okay with that
14:16 pmoreau: karolherbst: It could be interesting, but on the other hand, can’t we set up a repo on GitHub which frequently pulls from Ben’s repo, and run CI on that other account?
14:16 karolherbst: pmoreau: not afaik
14:17 karolherbst: mhhh another idea
14:17 karolherbst: pmoreau: I can create a CI repository with a .travis.yml file which just gets triggered daily or so
14:17 karolherbst: mhhh
14:17 karolherbst: okay, that might work
14:18 pmoreau: The main thing interesting here is CI. Pushing to it or so, is not that important as we will continue to use the ML for reviews and such, right?
14:18 karolherbst: we would need push rights for the .travis.yml file though :/
14:18 karolherbst: the good thing is, if it's inside the nouveau repository, it also works for forks and branches
14:22 mupuf: karolherbst: for my testing, I will need a real kernel tree
14:22 pmoreau: BTW, I’m not against having a common repo on GitHub, like there is for envytools. Just wondering how useful it would be.
14:22 karolherbst: mupuf: yeah, you get that
14:22 karolherbst: mupuf: my current travis file creates a kernel tree and compiles that
14:23 mupuf: karolherbst: great, so we could push it automatically to another tree
14:24 karolherbst: we could, yes
14:24 karolherbst: mhh so we would have something like nouveau-next and if we are feel happy, we would let ben merge it into his tree
14:24 karolherbst: and we clean up nouveau-next as we go?
14:24 mupuf: yeah
14:24 karolherbst: happy merge conflict resolving :D
14:25 mupuf: but we need to ask Ben to stop waiting for until the last second before pushing his code
14:25 mupuf: I am fine with having this repo rebased all the time
14:25 karolherbst: ben force pushes
14:25 mupuf: yes, but he waits too long for his patches to be perfect
14:26 mupuf: and that also means we don't get to check the patches out before they are sent to Dave... which does not really help the community
14:26 karolherbst: right
14:26 karolherbst: mupuf: my travis-ci file reads the git log for a "drm-next" commit anyway, so it doesn't really matter what we push there
14:27 karolherbst: everybody could push into their own trees as long as the .travis.yml file is there and it would get built. But having this file around is like super annoying
14:27 karolherbst: maybe we should setup our own CI server somewhere
14:31 mupuf: yep
14:52 dboyan: karolherbst: I'm seeing cpu lockups after reclocking while using NvBoost on 4.10
14:53 dboyan: I can see a warning from drivers/gpu/drm/nouveau/nouveau_bo.c:1212 nouveau_bo_move_ntfy+0xb2/0xc0
14:55 RSpliet: mupuf: wouldn't it be more helpful to have his WIPs in git branches?
14:55 mupuf: RSpliet: that makes testing harder
14:55 RSpliet: RE "he waits too long for his patches to be perfect"
14:56 mupuf: there could be master == tested and works fine
14:56 RSpliet: Do they need to be tested before he considers them perfect?
14:56 mupuf: staging -> master + current patchset
14:56 mupuf: RSpliet: absolutely!
14:57 mupuf: that reduces the development time
14:57 RSpliet: then is CI the right tool for that? Or should be he able to run the tests locally during dev?
14:57 mupuf: well, that is a fair point, Intel has the try bot
14:57 mupuf: you post to a ML and it tests your patchs for you
14:57 mupuf: https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated
14:58 mupuf: https://patchwork.freedesktop.org/series/21086/ <-- look here, the tests results
14:58 RSpliet: I know the mechanism, uboot uses this as well for instance. It's a standard feat of patchwork afaik
14:59 mupuf: you can even see that there is a known issue, so the patchset may not have cause the issue
14:59 mupuf: RSpliet: not on patch series ;)
14:59 mupuf: the only instance in the world with it is fdo
14:59 mupuf: I wish the code would have landed upstream though :s
14:59 mupuf: I wrote the code for tracking known issues
15:00 mupuf: That was this month's work, it is a pretty website that puts together test results, bugs, machines and tests
15:01 mupuf: the xmlrpc interface of bugzilla allows you to query the status, title and everything about a bug
15:01 mupuf: makes it quite nice to use :)
15:01 mupuf: And when there is a new untracked issue, it appears in a section, so you know you need to file bugs
15:02 mupuf: and yeah, that allows you to get information about issues in pre-merge testing
15:02 mupuf: (useful for unstable results)
15:08 karolherbst: mupuf: well with travis-ci every branch could be tested
15:08 mupuf: what do you want to test with travis-ci?
15:10 mupuf: you can only run HW-independent stuff, which is pretty lame :s
15:11 mupuf: it is good for testing compilation, but it does not randomize the .config either, so...
15:11 mupuf: So, what do you want to test?
15:16 karolherbst: ohh I see
15:16 karolherbst: well
15:16 karolherbst: Linus only cares about compilation and warnings :p
15:18 karolherbst: mupuf: well I want to test kernel combinations with different .config files
15:18 mupuf: karolherbst: ah ah, that is not true ;)
15:18 karolherbst: it's just not randomized
15:18 mupuf: And read Daniel's answer to this
15:18 mupuf: We talked about this, and the situation with kconfig is quite dire
15:18 karolherbst: mupuf: it's true, you know it :p If there wouldn't have been any warnings, he wouldn't have bothered that much :D ;)
15:19 mupuf: what Daniel said was that the code should be available early enough for the 0-day to take effect and try multiple combinations
15:19 mupuf: to some extent, yeah
15:19 karolherbst: aynway, it is an easy thing to test and we should do it
15:20 karolherbst: best would be, if this is already integrated inside our development cycle
15:20 karolherbst: push to branch -> 20 minutes later: you messed up
15:20 karolherbst: perfect
15:22 nyef`: I'd hesitate to call a 20 minute validation cycle "perfect", TBH, but I'm willing to agree that it's better than a longer validation cycle or a validation cycle that involves getting yelled at by Linus.
15:26 imirkin: dboyan: nouveau_bo_move uses the copy engine on kepler... sounds like something hung.
15:27 dboyan: turned off NvBoost, now it seems more stable
15:37 karolherbst: dboyan: can you pastebin your pstate file?
15:37 dboyan: karolherbst: does turning off NvBoost matter?
15:37 karolherbst: yes
15:38 dboyan: wait a minute
15:39 karolherbst: dboyan: or wait. Did you upload your vbios already?
15:39 dboyan: no, i don't think so
15:41 karolherbst: do you know what are the base/boost/max clocks for your GPU? and is is by any chance a GTX 650 or so?
15:42 karolherbst: or GTX 770 or some "OC" version or anything like that
15:42 imirkin: airlied: when is skeggsb back? like march 27?
15:43 imirkin:has stared at the NV44A PCI issue without much success.
15:45 dboyan: karolherbst: It's a GT 740M
15:45 dboyan: http://pastebin.com/XLtJ2Qih
15:45 dboyan: the gk208 one
15:46 dboyan: I set nouveau.config=NvBoost=1
15:52 dboyan: imirkin, I studied shader compiling in nvc0 a bit, and now I wonder what should be stored by on-disk cache
15:53 dboyan: nv50_ir_prog_info or nvc0_program or something in between
15:56 marmistrz: Hi! During the vacation I'd like to contribute to the nouveau driver, especially the OpenCL capability. I'm currently a newbie. I know about https://nouveau.freedesktop.org/wiki/IntroductoryCourse/ and it's something on my reading list. Is it feasible for me to help with the OpenCL capability? I'm currently having an operating systems course at the univerisity (we'll work precisely with Minix)
15:56 marmistrz: Besides, I'll be happy to help testing :) I have an GeForce 940M (Maxwell)
15:57 imirkin: definitely nvc0_program. also the binary code (duh) as well as the relocation and fixup info. i'd have to double check whether nv50_ir_prog_info is used after compilation. if it is, then yes, save it.
15:57 karolherbst: marmistrz: I highly doubt a vacation is enough time to learn enough to actually help out in a usefull manner, except we talk about a 3month+ vacation
15:57 imirkin: marmistrz: speak to pmoreau about opencl
15:58 karolherbst: marmistrz: allthough less time would be enough for smaller things, but yeah, speak with pmoreau
15:58 marmistrz: pmoreau?
15:58 pmoreau: Yeah, more people for OpenCL! \o/
15:59 pmoreau: marmistrz: There are a few things that shouldn’t be too difficult to do, and get you going with SPIR-V and such.
16:00 pmoreau: So, the main thing missing for OpenCL support, is feeding Nouveau some representation of the OpenCL kernels that it can understand. To achieve that, I am translating SPIR-V into the intermediate representation used by Nouveau.
16:00 pmoreau: There are a couple of other things missing, but that’s the biggest one by far.
16:00 dboyan: imirkin: I'm confused by the 'tfb' field in nvc0_program. It is constructed at the end, and depending on prog->pipe.stream_output. I suppose this can be safely cached?
16:01 imirkin: dboyan: that's a subtle one.... iirc the tfb is only used as a pointer value, not the data it points to
16:01 imirkin: it's used for deciding to reconfigure everything
16:01 imirkin: initializing it to 0 should be fine? i think?
16:01 pmoreau: marmistrz: You coud start by having a look at SPIR-V's whitepaper (https://www.khronos.org/registry/spir-v/papers/WhitePaper.html), and its spec (https://www.khronos.org/registry/spir-v/specs/1.1/SPIRV.html) (start with sections 1.9, 2.3 and 2.4).
16:01 marmistrz: pmoreau, SPIR-V is the OpenCL counterpart of Nvidia PTX?
16:02 pmoreau: It’s wider that just OpenCL, since it’s also used by Vulkan
16:02 pmoreau: And can also be used in OpenGL
16:03 marmistrz: But, just as PTX is a kind of assembly?
16:03 karolherbst: I think bytecord is the correct term?
16:03 pmoreau: It’s an intermediate representation
16:04 karolherbst: ohhh, true, it's an IR, silly me
16:04 karolherbst: whatever the difference between IR and bytecode is, cause since LLVM it became kind of the same
16:04 dboyan: imirkin: can the content of tfb be directly stored or it should be reconstructed after loading. If reconstruction is necessary, I guess we have to store something in nv50_prog_ir_info
16:04 pmoreau: So, you can’t inline SPIR-V inside an OpenCL kernel, like you can with PTX in CUDA kernels, and it has phi nodes which you wouldn’t have in an assembly
16:04 pmoreau: (I guess)
16:05 marmistrz: phi nodes?
16:05 imirkin: reconstruction of card state is necessary, but not of the shader. you should have a copy of the tfb handed to you already. the ptr is there, iirc, so that when you flip between programs that all share the same tfb state, you don't needlessly reconfigure the card. or something.
16:05 marmistrz: Does the rest of the introductory course on the nouveau webpage apply as well?
16:06 pmoreau: marmistrz: It’s a "merge" node in Single-Static Assignment https://en.wikipedia.org/wiki/Static_single_assignment_form
16:07 dboyan: imirkin: okay, I think that'll make my life easier. what's mainly left is to cleanly get the size of fixup and relocs outside codegen
16:07 imirkin: dboyan: but definitely look at how it's used... it's a little tricky.
16:07 pmoreau: marmistrz: I don’t think so. Some compiler knowledge should be more than enough, and pick up the rest on the way
16:08 dboyan: I'll have a try when I have time, but for now I'm going to bed
16:09 pmoreau: marmistrz: My current work is available here (https://phabricator.pmoreau.org/diffusion/MESA/repository/clover_binary/), with most of the work happening in https://phabricator.pmoreau.org/diffusion/MESA/browse/clover_binary/src/gallium/drivers/nouveau/codegen/nv50_ir_from_spirv.cpp
16:10 marmistrz: pmoreau, hmmm, I don't really have much compiler knowledge. From the low-level stuff I learned some assembly at the university, though.
16:11 pmoreau: marmistrz, tarragon: Here is some (possibly outdated) information on how to setup Mesa and the needed version of LLVM: https://phabricator.pmoreau.org/w/mesa/testing_opencl_through_spirv/
16:12 pmoreau: marmistrz: I started without much knowledge of compilers as well, which did not help, but I still managed to do some things. :-)
16:12 marmistrz: ;)
16:13 marmistrz: pmoreau, I should set up Mesa+LLVM so as to be able to do anything with OpenCL?
16:14 pmoreau: You could ignore LLVM, but that means either having to write the SPIR-V modules by hand (and trust me, you do not want to do that! I had too before that repo was made available by Khronos), or rely on someone else to give you the modules (which I could do)
16:18 marmistrz: i.e., it's really useful to have the LLVM setup
16:20 karolherbst: dboyan_: mhh, okay those clocks are indeed highish... could be a corner case where it really matters
16:21 karolherbst: dboyan_: you could try to figure out why we do wrong. Anyway, a mmiotrace of nvidia would be helpful
16:21 pmoreau: marmistrz: yeah, you probably want it :-)
16:22 marmistrz: pmoreau, I've added this to my TODO list, I'll meld back when I've done it. No ETA, since my university assigments take a lot of time ;) Do you want my e-mail?
16:22 karolherbst: marmistrz: interested in doing stuff as a GSoC project?
16:22 karolherbst: some universities even recognize this as a course and so on
16:23 pmoreau: marmistrz: No worries! I can PM you my address, and you can send me an email, or ping me on IRC, if you have any questions.
16:25 marmistrz: karolherbst, I need to complete an internship this year, I can see if it's recognized as an internship.
16:25 marmistrz: pmoreau, yes please :)
16:25 pmoreau: Done
16:25 karolherbst: marmistrz: the organization would be X.org
16:25 karolherbst: marmistrz: not "nouveau" or anyhting like this ;)
16:27 karolherbst: marmistrz: it isn't an internship though, but maybe your universities likes the idea, but you should ask rather now then later
16:27 karolherbst: *than
16:28 karolherbst: marmistrz: how long does the internship have to be?
16:28 marmistrz: at least 60 hours
16:28 karolherbst: ohh, that's like nothing ;)
16:29 karolherbst: GSoC is around 10 weeks I think
16:30 karolherbst: or 12 or so
16:30 karolherbst: marmistrz: here is the timeline: https://developers.google.com/open-source/gsoc/timeline
18:24 Jeggo: Who will be the sensei?
18:35 Jeggo: No matter if I read from Michael Abrash's Black Book or from wiki.osdev.org, all are talking about EGA/VGA. Is the knowledge of the VGA specs still of any use, if I want to draw on a screen connected to a x86 system, as low level as possible, without the BIOS' help? Or was it replaced by any successor in the meantime? If so, is there anything like Abrash's Black Book about the successor?
18:55 imirkin: Jeggo: in the bad old days, graphics cards were basically just scanning out vram, and the cpu would write the vram, which maps nicely onto vga. however nowadays, vga support is provided by an emulation layer set up by the option rom on most video cards. the lowest level would involve programming the gpu correctly to drive the screen and display things on it.
19:14 Jeggo: imirkin: So in the bad old days VRAM was memory mapped and the CPU wrote data in some format (RGBA?) to the memory mapped VRAM? The GPU thus was basically just a display controller - a bunch of RAM and a controller handling the connection to the monitor in a standardized fashion? Nowadays it is completely different, no matter which configuration the GPU is set to, VRAM is no longer memory mapped a
19:14 Jeggo: nd the CPU has other ways to pump a framebuffer to the VRAM? Or are my ideas of it completely wrong/outdated?
19:17 imirkin: the format depended on the vga mode being set
19:17 imirkin: the VRAM was mapped into a shadow section of cpu memory space
19:18 imirkin: at 0a0000h for graphics, 0b0000h for text (iirc... maybe 0b8000h?)
19:18 imirkin: for text modes, the video card had fonts
19:18 imirkin: etc
19:18 imirkin: nowadays these things are much more complex
19:19 imirkin: there's multi-head, not to mention DP-MST. people want to use the graphics card to compute the contents of the screen, all kinds of insanity
19:19 imirkin: fwiw i had a copy of the black book in HS ;)
19:22 Jeggo: I just have the virtual version :) Would be a nice book to have.
19:23 imirkin: we didn't have no innernet back in my day!
19:24 Jeggo: But the sneaker net ;)
19:25 imirkin: or in swim trunks
19:47 karolherbst: imirkin: which function can potentially return MAP_FAILED? my knowledge with the drm interface is not existing yet. Is it only os_mmap?
19:48 imirkin: mmap()
19:48 imirkin: but nouveau_bo_map() does a mmap :)
19:48 karolherbst: ohh os_mmap is just a mesa wrapper I geuss?
19:48 karolherbst: or libdrm
19:48 karolherbst: k
19:48 imirkin: os_mmap is a gallium helper
19:48 karolherbst: and nouveau_bo_map is part of libdrm_nouveau?
19:49 imirkin: yes.
19:50 karolherbst: ahh, it calls drm_mmap
19:50 imirkin: and you can make a guess as to what that calls :)
19:50 karolherbst: :D
19:50 karolherbst: I guess the return value of nouveu_bo_map can be MAP_FAILED as well
19:50 karolherbst: ohhh wait
19:50 karolherbst: no
19:50 karolherbst: it can't
19:50 karolherbst: mhh
19:50 karolherbst: odd
19:51 karolherbst: it returns -errno and sets bo->map to NULL
19:52 imirkin: ah. clever.
19:52 imirkin: well, i'm downloading hitman...
19:52 imirkin: not sure when i'll be able to test it out
19:52 karolherbst: :D
19:52 karolherbst: it's big, isn't it?
19:52 imirkin: 9G or so
19:53 karolherbst: only?
19:53 imirkin: i've seen bigger :p
19:53 karolherbst: ohhh true, it's without the dlcs
19:53 karolherbst: shadow of mordor was 62GB
19:53 imirkin: right
19:54 karolherbst: if you get annoyed by hitman, XCOM 2 is also something relativly new which could be tested
19:54 imirkin: and alien isolation i think
19:54 karolherbst: yes
19:54 karolherbst: there is another game we didn't get yet
19:54 imirkin: the new total war?
19:55 karolherbst: company of heros 2
19:55 karolherbst: *heroes
19:55 karolherbst: at least it's inside the game list of feral (linux)
19:55 imirkin: it's on my list... you sure?
19:55 karolherbst: ohhh, DLCs strike again
19:56 karolherbst: why are some of them listed as games....
19:56 karolherbst: okay, we got everything then
19:56 karolherbst: good, good
19:57 karolherbst: okay, now how to check for return value in a breakpoint
20:00 karolherbst: seriously... I have to do if $rax==0xffffffff at the end of the function? really?
20:09 pmoreau: Speaking of XCOM, XCOM 1 is misrendering, when I tried it on Maxwell and Fermi. Was going to open a bug report and attach an apitrace, but got stuck at trying to cut some frames from the api trace.
20:10 karolherbst: pmoreau: pro tipp: don't bother cutting
20:10 pmoreau: (there are all the logos in the beginning, which do not bring anything)
20:10 pmoreau: Ok, I’ll upload it as-is then.
20:11 pmoreau: Do you have access to it as well, or just the second one?
20:11 karolherbst: I have access to both
20:11 pmoreau: Ok
20:13 imirkin: yeah, cutting doesn't work
20:13 imirkin: outside of trivial traces, i've never seen it work out
20:13 karolherbst: pmoreau: I upload all my traces on a gdrive, this is good enough
20:13 karolherbst: there is even a cli tool for folder syncing
20:14 karolherbst: imirkin: huh... so that's odd
20:14 karolherbst: I doubt that 0xffffffff is a MAP_FAILED, or at least no MAP_FAILED which retursn from nouveau_bo_map
20:15 karolherbst: ohh wait, doesn't make sense anyway
20:27 karolherbst: mhh odd, turning on MALLOC_CHECK_ crashes the game in random places...
20:28 pmoreau: My bad, it renders fine on Fermi, so it’s only on the GM206 that it misrendered. That, or something got fixed recently.
20:29 karolherbst: mhh valgrind is like super slow :/
20:29 imirkin: pmoreau: well, i'm aware of at least one thing wrong on GM200+ - polygon offsets are not applied properly
20:29 imirkin: we're probably missing an enable bit somewhere
20:29 pmoreau: Ok
20:30 imirkin: this in turn can cause objects to now show properly
20:30 imirkin: mostly "decals", or for z-fighting to occur
20:30 pmoreau: Yeah, it looks like objects fighting to be rendered on top, or being too transparent/dark IIRC
20:31 imirkin: might be it - if you have blob set up, a trace of a polygon-offset test would be great
20:31 pmoreau: Should be doable
20:31 imirkin: maybe we're supposed to write the units of polygon offset somewhere, instead of guessing based on format like other chips
20:31 pmoreau: Let me plug in the correct card
20:36 pmoreau: Yup, still broken on Maxwell. Let me get a trace then. mmt trace?
20:38 imirkin: ya
20:38 imirkin: of polygon-offset, under blob
20:44 pmoreau: So, `./bin/polygon-offset -fbo -auto`, right?
20:48 imirkin: pmoreau: should be enough i think
20:49 pmoreau: There you go: https://phabricator.pmoreau.org/F111736
20:49 imirkin: pmoreau: while you're at it...
20:49 pmoreau: Sure
20:49 imirkin: bin/ext_polygon_offset_clamp-draw -auto
20:49 imirkin: that may be a simpler test to analyze
20:50 imirkin: bleh
20:50 imirkin: demmt doesn't like your blob =/
20:51 pmoreau: :-(
20:51 pmoreau: Here is the other test: https://phabricator.pmoreau.org/F111737
20:51 imirkin: thanks
20:51 pmoreau: It demmt didn’t complain on my end, but I haven’t really looked through the results
20:52 pmoreau: s/It//
20:52 imirkin: well, it's just not decoding
20:52 pmoreau: It had decoded some stuff for me, but probably not enough… :-(
20:52 imirkin: which means that i need to do some debugging as to why
20:53 pmoreau: For information, I am running 378.13.
20:55 karolherbst: is there a really nice way to speed up memgrind and stll be usefull for debugging silly bugs?
21:11 pmoreau: karolherbst: Where is the screenshot folder on Linux for Steam?
21:13 imirkin: very odd. looks like the value is being set via some weirdo methods.
21:13 pmoreau: Making your way through the raw data? :-)
21:14 imirkin: yes.
21:14 imirkin: it's calling some macro
21:14 imirkin: to set the value
21:14 imirkin: which is extremely odd
21:14 imirkin: esp as the macro parameters are the register id and the value
21:15 imirkin: which means that it's a semi-generic macro
21:15 imirkin: which is used to annoy me.
21:15 imirkin: [with some success it seems]
21:17 imirkin: on the bright side, i can use some old traces to "RE" it.
21:17 glennk: karolherbst, --toggle-collect=<function> perhaps?
21:18 imirkin: grrrrrrrrrrr. extrinsrt. i have to re-figure out wtf the args are.
21:19 imirkin: it takes 5 args, all bad.
21:20 karolherbst: glennk: it seems to be "fast enough" with --tool=memcheck --leak-check=no set already :/ but it still takes ages
21:20 karolherbst: glennk: maybe I should limit to mesa libraries
21:21 karolherbst: pmoreau: no idea
21:28 karolherbst: glennk: seems like that toggle-collect is not for memcheck...
21:32 imirkin: ok, so that macro appears to be a no-op, except that it can be used to disable a bunch of stuff in a saved command stream. which ... is weird, but i'm sure there's some weird use-case.
21:32 Echelon9: pmoreau: I made a small addition to the envydis documentation PR that we discussed, should be ready to merge
21:34 pmoreau: Echelon9: Ok, cool, I’ll have a look after dinner.
21:44 imirkin: pmoreau: aha, looks like it's the chipset version detection thing. i was able to force it.
21:50 pmoreau: Oh, cool! :-)
21:55 imirkin: pmoreau: do you still have the setup?
21:56 imirkin: looks like GET_CHIPSET is returning an error, which iirc mslusarz pointed out earlier. (that's how i noticed)
21:56 pmoreau: Sure, I still do
21:56 pmoreau: And the computer is still running
21:56 imirkin: could you try modifying valgrind/mmt/nvrm_mthd.h::nvrm_mthd_subdevice_get_chipset and add uint32_t unk to it
21:56 imirkin: one at a time
21:56 imirkin: until the demmt starts working
21:56 pmoreau: Ok
21:56 imirkin: (you'll need to take new mmt's each time with the updated mmt build)
21:57 pmoreau: Makes sense
21:58 imirkin: e.g. right now in the demmt you should see a line like
21:58 imirkin: [class: 0x2080 NVRM_SUBDEVICE_0], mthd: 0x20801701, ptr: 0x0000000802b3bc98, size: 0x0000000c, status: 0x0000003a
21:58 imirkin: er, shoot
21:58 imirkin: LOG: NVRM_IOCTL_CALL post, fd: 5, cid: 0xc1d00068, handle: 0xbeef0004 [class: 0x2080 NVRM_SUBDEVICE_0], mthd: 0x20801701, ptr: 0x0000000802b3bc98, size: 0x0000000c, status: 0x0000003a
21:58 imirkin: the status 0x3a is something bad
21:59 imirkin: as you add uints to that struct, you should see the size increase
21:59 imirkin: ideally it's just complaining that the size is too small
22:05 imirkin: in the meanwhile i have a patch that makes demmt less crashy
22:09 pmoreau: Hum… if I add a single uint, the GET_CHIPSET method is nowhere to be found
22:09 imirkin: gr
22:10 pmoreau: Let’s add some more :-D
22:10 imirkin: hold on
22:10 imirkin: perhaps demmt is being lame?
22:10 imirkin: try adding the int to demmt also
22:10 pmoreau: Ah, ok
22:11 pmoreau: Where would that be in demmt?
22:11 imirkin: nvrm_ioctl.h
22:15 pmoreau: I had more luck with demmt/nvrm_mthd.h ;-)
22:15 imirkin: i was close :op
22:15 pmoreau: yup
22:20 pmoreau: Ok, it seems happy with a single extra uint
22:20 imirkin: does status = success now?
22:20 pmoreau: Yup
22:20 imirkin: neat
22:20 imirkin: so NOW we have to (a) make sure that demmt can deal with both
22:21 imirkin: and (b) check if old blobs can work with the larger size
22:21 imirkin: and if not, then cry loudly
22:22 pmoreau: How does demmt feel about this one? https://phabricator.pmoreau.org/F111801 I have generated it with the extra uint
22:23 imirkin: feel free to xz -9 these btw - demmt can unxz on the fly
22:23 imirkin: looks perfeclty happy, but for some odd reason doesn't print the GET_CHIPSET thing
22:23 pmoreau: There are ~2MB, I can waste that much space without any issues! :-D But good to know
22:23 imirkin: however it does detect it just fine
22:24 pmoreau: Have you added the extra uint to demmt?
22:24 imirkin: i have not.
22:24 imirkin: but LOG: handle: 0xbeef0003 [class: 0x0080 NVRM_DEVICE_0], chipset: 0x126
22:24 imirkin: so it's all happy
22:24 pmoreau: It did not show it for me, until I added it to demmt
22:24 pmoreau: Yeah! :-)
22:24 imirkin: the question is what if you take an old blob version
22:24 imirkin: and feed it an ioctl with 4 uints
22:25 imirkin: i.e. size = 0x10
22:25 imirkin: will it die
22:25 imirkin: or will it just fill in the first 0xc bytes
22:25 pmoreau: Good question
22:25 imirkin: we def have to support 340.x since that's the last of the tesla support series, for exmaple
22:26 pmoreau: Yup
22:28 imirkin: of course none of this explains why polygon offset fails on GM20x
22:28 imirkin: do the tests themselves pass under blob?
22:30 pmoreau: They do
22:30 imirkin: =/
22:33 imirkin: pmoreau: can you try setting 0xf64 = 0x1000080 ?
22:33 imirkin: [if you don't mind switching back to nouveau]
22:34 pmoreau: One sec, I’m trying to find out where the screenshot went, so that I can add it to the bug report
22:34 imirkin: yea whenever
22:39 pmoreau: Found it! Screenshots are in `${HOME}/.steam/steam/userdata/${STEAM_USER_ID}/760/remote/${APP_ID}/screenshots`
22:39 pmoreau: And bug submitted
22:39 pmoreau: Now, reboot time
22:40 pmoreau: Where do I need to set 0xf64 btw?
22:42 imirkin: nvc0_screen.c is fine.
22:43 pmoreau: Sorry, I do not get what you mean by setting 0xf64 = 0x1000080
22:43 imirkin: BEGIN_NVC0(push, SUBC_3D(0xf64), 1); PUSH_DATA(push, 0x1000080);
22:43 pmoreau: Ah, ok
22:44 pmoreau: And I plop that function call anywhere in nvc0_screen.c?
22:45 imirkin: around the other init stuff yea
22:47 karolherbst: \o/ it left the loading screen
22:47 pmoreau: \o/
22:48 karolherbst: avg fps is 0.42
22:48 imirkin: almost there!
22:48 karolherbst: good enough
22:49 karolherbst: hu: "Warning: client switching stacks? SP change: 0x42c28468 --> 0xcffdc860" why should a client do that at all anyway? well except it has a JIT or something like that
22:49 pmoreau: imirkin: I put it in `nvc0_magic_3d_init()`: the name seemed perfect for it! ;-) Recompiling now
22:50 karolherbst: at least intel doesn't sync to that fps... that would have been annyoing
22:51 pmoreau: It’s not that bad if you are still talking about fps, rather than fpm! :-p
22:51 imirkin: pmoreau: and just run the tests, no point in running the game, in case it's not clear
22:52 pmoreau: I was going to run the test :-) It just looks like I haven’t compiled Mesa in some time on that computer, so it’s taking a bit longer
22:53 karolherbst: we need to fix those "gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b000e [OOR_ADDR] " anyway, cause they occur like every frame
22:55 karolherbst: by the way: with a decent nvidia GPU shadow of mordor is quite playable with nouveau
22:55 karolherbst: if it doesn't crash
22:55 imirkin: karolherbst: so what i'm hearing is that i shouldn't try it with my un-reclocked GF108?
22:55 karolherbst: :D no
22:55 karolherbst: I got around 20 fps on mine
22:55 imirkin: so i should get 0.2fps
22:55 karolherbst: yeah
22:56 pmoreau: imirkin: Weird: if I just run `./bin/ext_polygon_offset_clamp-draw`, it runs six sub-tests, with two of them failing. If I run with `-auto` as well, it only runs 2 of them, which pass.
22:56 imirkin: hrm
22:56 karolherbst: \o/
22:56 imirkin: pmoreau: what about the polygon-offset piglit?
22:56 pmoreau: It fails as well
22:56 karolherbst: imirkin: this looks like something: https://gist.github.com/karolherbst/e4d02733e0bb7689dc3a5a531496be69
22:56 imirkin: pmoreau: i only get 2 subtests...
22:57 karolherbst: maybe unrelated, but still an issue
22:57 imirkin: gah
22:57 imirkin: they created too many textures.
22:57 karolherbst: hihi
22:57 imirkin: iirc we don't handle that case SUPER gracefully
22:58 karolherbst: well, we shouldn't do an invalid write either way
22:58 karolherbst: the game still runs by the way
22:58 imirkin: i agree :)
22:58 imirkin: it's just ... never-tested
22:59 karolherbst: I will add new foundings to that gist, let's hope we find the reason for the crash as well
22:59 karolherbst: or maybe it is something like that
22:59 pmoreau: Oh great, X just died…
22:59 imirkin: pmoreau: wait, but ext_polygon_offset_clamp-draw -auto passes now? it failed before right?
23:00 pmoreau: Well, if I run it with auto, it passes, but without it, some of them fail
23:00 pmoreau: I was going to paste the results, but X died
23:00 pmoreau: One sec
23:02 pmoreau: https://hastebin.com/erarofajas.erl
23:02 pmoreau: I get the same on 17.0.1
23:04 karolherbst: wuhu, my script still works: https://gistpreview.github.io/?f6d5e89c6a45c3f3a3178880a3421d55/test.html
23:04 karolherbst: mhh, I could add the game publisher
23:13 karolherbst: what the heck valgrind....
23:13 karolherbst: "More than 1000 different errors detected. I'm not reporting any more.".....
23:14 karolherbst: okay, but that crash didn't happen now
23:15 imirkin: pmoreau: weird. but polygon-offset just fails either way, irrespective of setting 0xf64
23:23 karolherbst: imirkin: I doubt I can simply increase NVC0_TIC_MAX_ENTRIES?
23:23 pmoreau: imirkin: Right
23:23 imirkin: pmoreau: ok. so there's more.
23:24 imirkin: karolherbst: maybe? not sure.
23:26 karolherbst: seems like I can't
23:29 karolherbst: :D and I know why
23:31 imirkin: you'd need to increase the tic table size as well
23:32 karolherbst: yeah
23:33 karolherbst: https://gist.github.com/karolherbst/40743005971d9e5dd061bd71537337db
23:33 karolherbst: we should just do it the right way
23:33 karolherbst: okay, more issues left though
23:36 karolherbst: hum :/
23:37 karolherbst: have to sleep anyway, will look into this another time