00:00karolherbst: 3 rooms and I have only one roommate
00:00hakzsam: nice place
00:00karolherbst: living room has quite some place (~ 22 m²)
00:00hakzsam: I think you forgot mupuf :)
00:00karolherbst: I already told him
00:01mupuf: karolherbst: congrats on your new place!
00:01karolherbst: we get the keys on the 13th this month
00:03karolherbst: and we get even a 400MBit internet connection (hopefully) with 25Mbit upload
00:03karolherbst: so I guess I could also create a reator or something
00:03karolherbst: actually I plan this anyway
00:04hakzsam: reator2 :)
00:04karolherbst: mupuf: you need to tell/show me how I have to do this by the way then ;)
00:04karolherbst: I plan to do it around june or earlier
00:04mupuf: karolherbst: yep!
00:06mupuf: I started working today on controlling multiple machines running ezbench
00:06karolherbst: maybe I build a PCIe multiplexer with a controller to switch GPUs on the fly or so
00:06mupuf: that will include ways to turn on machines as needed
00:07mupuf: karolherbst: no way you can do that...
00:07karolherbst: why not?
00:07mupuf: because lanes have to be the exact same length and impedence
00:07mupuf: and blabla öD
00:07karolherbst: okay, impedence might bceome a problem
00:08mupuf: yes, it would ö=
00:08mupuf: sorry, finnish layout, back to us
00:08karolherbst: your ö is on an odd key
00:08karolherbst: ohh wait
00:09karolherbst: nono, it's fine :D
00:09mupuf: but yeah, I have 10 circuits for wtrpm on the way to finland
00:10mupuf: so, if they do work, I will actually make more of them (or even ask the chineese to populate the board for me)
00:10mupuf: I may end up using the same system at intel, for developer machines
00:11karolherbst: maybe I just buy a MB with 4 slots... makes more sense than a multiplexer
00:11mupuf: yes, it does
00:11mupuf: and better buy more machines than one very expensive one
00:11mupuf: more machines == more testing done in //
00:12karolherbst: we hardly need 2 reators
00:12mupuf: yes we do, mister
00:12karolherbst: it's very rare we really need both at the same time
00:12karolherbst: yes it happens, but having two machines is enough for now
00:12mupuf: true, but what about automated testing?
00:13karolherbst: more slots make more sense on a testing rig.... mhhh
00:13mupuf: well, not really
00:13karolherbst: one of each family
00:13mupuf: if it takes 12 hours to run all the tests, then the machine is out for 2 days
00:13karolherbst: and then we can automatically test all
00:13karolherbst: then we need a faster machine
00:14karolherbst: 170€ for a board with 4x pcie x16?
00:14mupuf: well, you can get one expensive machine, or 4 scrap ones ;)
00:14karolherbst: 3 slots accessable with dual lane cards
00:15mupuf: I have the perfect cabinet to put up to 6 machines
00:15mupuf: or more actually, if needed. But let's start small
00:16mupuf: I already have 2 machines to hook up, the nv86 and the tk1
00:16mupuf: when this works, I will just ask nvidia for the tx1 and add more testing
00:16mupuf: err, hw
00:17mupuf: the only GPUs that will be hard to test will be the fast ones... the 690 and the titan
00:17mupuf: because they will need a beefy CPU
00:20karolherbst: meh... feral didn't fix their libcurl issues yet
00:23karolherbst: ohhh graphical issues with hitman :)
00:23karolherbst: and gpu crash :D
00:26imirkin: hmmm... OOR_ADDR shouldn't be fatal
00:26imirkin: in some situations it can even be expected
00:26karolherbst: I didn't update my system mesa as well
00:27karolherbst: so your fixes aren't there yet
00:27imirkin: which ones?
00:27karolherbst: currently installing
00:27karolherbst: the hitman ones
00:27imirkin: the hitman-specific ones?
00:27imirkin: probably want those ;)
00:28imirkin: note that this patch still hasn't been pushed - st/mesa: set result writemask based on ir type
00:28karolherbst: yeah, but that only hit an assert
00:29karolherbst: but there are enough issues to work with :)
00:31karolherbst: crap :D the menu is so broken, I can't select the benchmark
00:31karolherbst: at least it doesn't crash
00:33karolherbst: anyway, will look into it in more depth over the week
00:34imirkin: ok cool. make traces.
01:06tarragon: how's wine with nouveau?
01:07tarragon: so far success with 'winecfg'
01:09nyef`: Hrm... HDMI and DPort output at the same time might mess up HDA?
01:10nyef`: ... No chance of me testing that properly until next week, but I may be able to connect to both HDMI inputs on my TV here.
01:11Lyude: imirkin_: I -think- I've added all the stuff I need in mesa's core and gallium (gallium didn't seem to need much), would it be a good idea for me to try to implement this in the softpipe driver first? or just go straight to nouveau
01:11nyef`: Or not, looks like the mini-DP to HDMI adaptor is at home.
01:13mooch2: so, update on my nvidia emulation
01:14mooch2: one specific user of 86box has managed to get the nvidia riva 128 drivers installed
01:14mooch2: i haven't been able to reproduce that, but still
01:15imirkin: Lyude: well, the downside of doing it in softpipe is that you'd have to implement it
01:15Lyude: hehe, I figured you'd say that
01:15imirkin: for nvidia, you just write a 1 or a 0 to a register, and presto-changeo -- it works
01:16imirkin: i'm fine either way, as you can imagine.
01:16Lyude: it might actually be more useful in that case for me to implement it in nvidia first and see what happens from there, so I have a working reference to go off of
01:18Lyude: neat, didn't realize it'd be this easy :)
01:19imirkin: well, ideally you would have written piglit tests :p
01:20imirkin: should be easy to hook it up in shader_runner if you don't want to write real code
01:20Lyude: i was already planning on doing that
01:20Lyude: also, what is shader_runner?
01:20imirkin: [i highly recommend that path btw... writing real code is for suckers]
01:20imirkin: find piglit -name shader_runner.c
01:21imirkin: basically a thing that processes shader_test files which are effectively little GL scripts
01:33Horizon_Brave: Hi everyone
01:34dboyan_: imirkin: What's the difference between LIMM and I3BIMM?
01:35dboyan_: I'm deciding which to use for F2F.F16.F16
01:35Horizon_Brave: sweet...I'm not the only one who comes with questions...lol
01:35dboyan_: well, 16 bit value
01:35dboyan_: Horizon_Brave: yeah ;)
01:36Horizon_Brave: dboyan_: lol...I always feel like I ask more than I give though :\
01:44imirkin: dboyan_: floating point imms are the top 20 (or 19) bits. integer imms are the lower 20 bits.
01:45imirkin: dboyan_: i dunno what to use for F2F.F16.F16 - you'll have to play with the decoding
01:45imirkin: in nvdisasm
01:45Horizon_Brave: Rutgers... Jvesely, which rutgers campus are you at?
01:55dboyan_: imirkin: I3BIMM for f16 immed value, because they only has 16 bits
01:56dboyan_: *have 16 bits
01:57dboyan_: well, talking on irc reveals that my english is quite broken...
02:01Horizon_Brave: lol, don't worry my English breaks on irc AND in normal speech :P
02:09Horizon_Brave: Hey, if the Nouveau team decides to drop support/code for an older nvidia card, in a newer release of nouveau...and a user has that card, and the decision won't allow him to use it anymore, are options availble to "add " the removed code back into the nouveau package?
02:09mupuf: Jetson TX2... how to screw up a logical naming convention...
02:09mupuf: I guess TP1 was a bad name
02:09mupuf: were they afraid of people using toilet paper on their product?
02:13gnarface: have any cards actually been removed from nouveau support? i thought the goal was to support all of them.
02:14gnarface: (pending finding hardware to actually test with)
02:14dboyan_: well, why did they come up with TX1 in the first place instead of TM1?
02:15Horizon_Brave: gnarface: really? wouldn't that eventually result in a massively bloated package eventually? if it pulled in every single driver needed to support every card that nvidia makes?
02:16Horizon_Brave: gnarface: I'd think eventually it would just outgrow a practical sized package?
02:17gnarface: oh, i don't actually know for sure. in theory, yes. in theory the sun will run out of fuel and implode eventually too.
02:17gnarface: in practice, material goods don't tend to last that long
02:18gnarface: usually support gets removed when people stop complaining about it (evidencing the hardware in the wild has all died)
02:18Satchelboi: Hey, is anyone working on the nv_conservative_raster for gm200 currently?
02:18airlied: open source driver don't generally drop support, they just rot
02:19gnarface: also, probably they could keep adding new nvidia card support to nouveau for the next thousand years anyway before the file size of the binary itself is any sort of reasonable concern
02:19Lyude: imirkin: see Satchelboi's message ^
02:19Lyude: wrong window, whoops
02:21airlied: nouveau also isn't a single package
02:22Lyude: Horizon_Brave: as well a lot of drivers for different generations, almost all of them really, usually share code with other generations
02:23Horizon_Brave: right..all valid points..
02:24Horizon_Brave: so with the facts that most drivers are compiled using shared libraries...and are generally similar to each other, and that binaries are very small in file size, the developers can generally add to the nouveau package and not really worry about the size becoming unweildy...
02:25airlied: Horizon_Brave: you might want to look at how nouveau is distributed
02:26gnarface: Horizon_Brave: nvidia only rolls off support for their old cards to force you to buy new ones
02:26airlied: well it decreasse their support costs and QA costs
02:27airlied: Horizon_Brave: most of nouveau is in the Linux kernel, and the mesa dirvers
02:27airlied: the X nouveau package isn't even necessary for newer cards
02:27Lyude: also, looking at adding the register change to rasterization in nvc0_state.c to add support for NV_fill_rectangle and I'm a little confused: what exactly do SB_BEGIN_3D, SB_DATA, and SB_IMMED_3D do? I assume they're some sort of commands we send to the GPU but what is the difference between all of them
02:28Horizon_Brave: speaking of which....
02:29airlied: Lyude: SB_BEGIN_3D starts a new command with a specified number of dwords, SB_DATA contains the dwords
02:29airlied: SB_IMMED_3D does a command that takes one 32-bit value
02:29Horizon_Brave: what kind of hoops does the nouveau team go through to get accepted into the official linux kernel? Was the nouveau team approached by the kernel um... "developers?"
02:29Horizon_Brave: or does the nouveau team have to present their code and request to be included in the linux pristine kernel?
02:30gnarface:assumed they were already kernel developers when they founded the driver
02:30gnarface: there was an older "nv" driver already there it replaced
02:30imirkin: Horizon_Brave: no support for any GPUs have ever been dropped from nouveau
02:30imirkin: airlied: Lyude: IMMED_3D actually only lets you have 12 bits iirc of value. if you want more bits, then you can't use it.
02:31airlied: imirkin: ah interesting
02:31airlied: Horizon_Brave: they are just like any kernel driver, nothing special
02:31Lyude: it should be noted a good number of widely used drivers in the kernel are reverse engineered, or started off as such
02:32Lyude: imirkin: alrighr
02:35imirkin: airlied: there are asserts in at least IMMED_NVC0 to complain... or i think there are.
02:35imirkin: airlied: since it's a 32-bit command word, kinda hard to store 32 bits worth of value :)
02:36dboyan_: imirkin: i'm a bit unsure about cvtf2isrc equivalent in tabi. Shall I create a new table for it? How should they be named?
02:37Echelon9: nice to see the TX2 (Pascal) announced.
02:37Echelon9: Although surprising the Jetson developer series remain so expensive when you can get the same chip, storage etc in a Shield TV with unlocked bootloader
02:37imirkin: Lyude: here is a description of how FIFO command processing works: http://envytools.readthedocs.io/en/latest/hw/fifo/dma-pusher.html#the-commands-pre-gf100-format
02:38imirkin: Lyude: the immediate commands were added in GF100, so you have to scroll down a bit to see them
02:38gnarface: Echelon9: wait, the Shield TV doesn't have a locked bootloader????
02:38Echelon9: it does not. I've booted my own compiled 3.whatever series kernel fork that nvidia provides; and I'm trying to get an upstream 4.10 kernel booting too
02:39imirkin: dboyan_: not sure... i suspect i'd have to investigate it as much as you would to figure out the answer, so you can go ahead and propose something yourself. or just leave those out if you don't feel like dealing with them.
02:39Lyude: imirkin: thanks! also, Satchelboi (friend of mine jfyi, trying to get them into graphics too :) was wondering if they could take https://trello.com/c/Zjm7vs5h/149-gm200-nv-conservative-raster
02:39Lyude: or rather, just make sure no one else is working on it
02:39imirkin: Satchelboi: i don't think anyone's working on NV_conservative_raster.
02:39Lyude: I remember what you said about people coming and going ;)
02:40imirkin: that they do. iirc Satchelboi was here earlier too (at your behest)
02:40Lyude: yeah, they're hoping to do gsoc
02:40Satchelboi: Hopefully I'll be able to make some progress with this one as a starter project.
02:41imirkin: sounds like a fine starter project. assuming it's a relatively trivial implementation on gpu, should take no more than a couple days to figure it all out (that's counting figuring out tools, how nvidia works, etc)
02:41Echelon9: skeggsb: For the new mem types in the nouvea kernel, I'm going to just submit a patch for detecting GDDR5X. HBM2 can wait
02:42Satchelboi: Then I best start working towards figuring out tool and driver functions tonight so I can progress on the actual implementation.
02:43imirkin: Satchelboi: as you can see in the trello card, someone already did a bit of playing with that ext. however it was incomplete - didn't figure out the subpixel bits of the ext.
02:43imirkin: so not AS easy as the one Lyude is working on, but should be close
02:44Satchelboi: I'll pick up from that point and see what I can do then.
02:44imirkin: so you need a setup where you can trace the nvidia driver
02:44imirkin: oh, and in case it's not obvious, you also need a GM20x gpu :)
02:45Satchelboi: I have access to a gm20x card, so that won't be an issue luckily.
02:46imirkin: do you have a grasp of how rasterization works?
02:46Lyude: yeah, I'll be letting them ssh into the machines i've got here
02:46imirkin: (if you say "yes", i'll know you're lying...)
02:47Satchelboi: I just read a general overview on how they work. After that, it's a work in progress.
02:47Horizon_Brave: what are you trying to do Satchelboi? if you don't mind me asking?
02:48imirkin: Satchelboi: so the idea of conservative rasterization is that a pixel is lit up if any part of it overlaps with the triangle, rather than just if any of the samples are covered
02:49Satchelboi: Horizon_Brave: I'm looking into working on the nv_conservative_raster tag, though I'm still trying to figure out exactly what it's asking to be done.
02:49imirkin: having a solid grasp of all that stuff should be immensely helpful when writing piglit tests
02:49imirkin: my guess is that you'll think you get it, write the tests, they won't work, and you'll adjust your understanding until they do work :)
02:50Satchelboi: If that's what it takes to understand it well, then I'm happy to give it a shot.
02:50Horizon_Brave: I really...should have stuck with CS as my major... I went into IT instead... you guys seriously speak a different language than us lol...
02:50imirkin: coming up with good ways to test rasterization is extremely hard as well
02:50imirkin: Horizon_Brave: lots of graphics-specific talk in here too, as you might imagine.
02:51imirkin: Satchelboi: you could look at the INTEL_conservative_raster tests for inspiration... hopefully there are some
02:51Horizon_Brave: heh, oh yes, If I hear the word raster one more time.... :P
02:51Satchelboi: No better time to starting learning those terms then!
02:51Satchelboi: imirkin: I'll take a look at those first
04:02Lyude: For a patch series, if I need some registers in src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h that aren't there right now because the files haven't been regenerated in a while, should I go about regenerating the whole thing?
04:49Echelon9: Can I interest anyone in a quick envytools documentation PR review?
05:08mattst88: Lyude: no 1.0.14 tarball?
10:18hakzsam: Lyude: my advice: you are going to have serious headaches if you try to regenerate the whole file (lot of things have been renamed, etc). You should just put them directly in the header :)
14:05dboyan: imirkin_: I found a case in my rsq where it had 3ulp difference with cpu
14:18dboyan: well, I guess I've found the problem.
14:21dboyan: I might still need normalization in rsq, seems that error accumulates on some small normalized values
14:25imirkin_: Lyude: yeah, i applied some sed commands which aren't anywhere last time i generated those files. just add it in by hand and make it look reasonably like the other lines.
14:28imirkin_: dboyan: 3 ULP is still pretty good... might be enough for RSQ. let me check.
14:28imirkin_: dboyan: also, for that value, can you check the "real" answer, since cpu might also be off
14:28imirkin_: i don't think that CPU has a <= 1 ULP guarantee for those
14:29imirkin_: dboyan: inversesqrt <= 2 ULP
14:29imirkin_: dboyan: btw, next is sqrt :) that one should be ... fun.
14:29imirkin_: [since 1/rsq doesn't have nearly enough precision]
14:30dboyan: imirkin_: The problematic number has 1 in exponent, when i changed it to 3, it suddenly became saner
14:30imirkin_: i thought you did exponent and mantissa separately
14:30imirkin_: oh, but you're using rsq64h. nevermind
14:30imirkin_: iirc the blob code does some amount of exponent normalization (or de-normalization?) before feeding the data to rsq64h
14:31dboyan: they did iirc, and in a rather sophisticated way
14:31imirkin_: perhaps they knew what they were doing? :)
14:32dboyan: i know what they are doing, but it shouldn't be that twisted
14:32imirkin_: heh. "should" and "floating point" often go counter to each other
14:34dboyan: imirkin_: btw, do you think can unify the various f2f forms of cvt in envydis?
14:34dboyan: The big problem is about rounding flags
14:35imirkin_: i don't really see how you'd do it...
14:35imirkin_: you could make a tabcvt or something which has the different things
14:35imirkin_: but that just shifts the lines around a bit...
14:35imirkin_: doesn't end up in fewer lines :)
14:35dboyan: okay, then I'd rather keep it as it is
14:35dboyan: there are some missing flags though
14:36imirkin_: yeah, the gk110 isa spec is the least "done" one
14:36imirkin_: it was created at a time before nvdisasm was known/used
14:36imirkin_: so it was purely through ptxgen
14:38dboyan: I guess it was pretty hard work then
14:38imirkin_: before my time :)
14:39imirkin_: (or at least before i was looking at post-nv50 stuff.
15:03dboyan: imirkin_: I guess i'm just too lazy, but I think applying the same handling of denorm to values with 1 (or 2) in their exponent should fix the problem
15:03imirkin_: dboyan: makes sense.
15:03dboyan: There was a * 0.5 at the beginning, and those with 1 in exponent will lose precision
15:03imirkin_: since sqrt(exponent = 1) would end up as a denorm
15:04dboyan: the * 0.5 thing is at the beginning newton-raphson step
15:04dboyan: so no matter how many rounds, it gets the same error
15:05imirkin_: silly question...
15:05imirkin_: can you check the REAL mathematical answer to the question you're asking
15:05imirkin_: and see how that corresponds with your value?
15:05imirkin_: the cpu could be off :)
15:06dboyan: are there things like *precise* implementation of floating point arithmatics? I wonder too
15:07imirkin_: but you can use a non-floating point impl to compute the value
15:07imirkin_: and then convert it back into floating point
15:10dboyan: Maybe not that easy either. I guess reciprocal and sqrt are not trivial to implement
15:11imirkin_: no, but people have implemented them
15:11imirkin_: e.g. BigDecimal in java
15:12dboyan: hmm, do you think I should check against them before I roll out another round of patches?
15:12imirkin_: i'd check some of those weird ones
15:12imirkin_: not all of them
15:13imirkin_: btw, you can access that stuff easily with jython
15:13imirkin_: ok, i lied, BigDecimal doesn't do it. but there are libs.
15:15imirkin_: dboyan: http://www.leda-tutorial.org/en/discussion/ch06s03.html
15:15imirkin_: apparently LEDA is such a library that has "bigfloat"
15:16imirkin_: Source Code is not available for free, but can be purchased from us
15:17imirkin_: probably something written in fortran has it :) they solved a LOT of nasty problems in fortran
15:17imirkin_: dboyan: but maybe you can use e.g. wolframalpha.com for it
15:20dboyan: well, that there are still many 2ulp differences, but 3ulp ones seems gone
15:20dboyan: I'll check and see
15:21dboyan: I ran at least 100M tests, none exceeding 2ulp
15:27dboyan: rcp seems rather precise though, none of the error is greater than 1ulp as of now
15:28imirkin_: oh cool
15:42karolherbst: imirkin_: I can check something with BigDecimal if you want to :D
15:43imirkin_: karolherbst: it doesn't have rsq =/
15:43dboyan: imirkin_, I found mpfr
15:44karolherbst: imirkin_: http://stackoverflow.com/a/17306433
15:45karolherbst: ohh wait
15:45karolherbst: you wanted rsqt
15:45imirkin_: yeah, and *precise*, not some random algo some guy copied from some place and put up on stackoverflow
15:48karolherbst: maybe this helps
15:48imirkin_: mpfr should be fine
15:49dboyan: my current plan is to validate the result with mpfr when there is difference greater than 1ulp
15:50dboyan: will implement that tomorrow
15:53imirkin_: dboyan: sounds good. i'll be curious to know how the CPU impl fares :)
16:05imirkin_: RSpliet: getting info on what you're actually seeing in demmt would be great
16:05imirkin_: and/or the trace itself
16:05imirkin_: from a brief look, it should all be hooked up
16:07imirkin_: RSpliet: perhaps it uploads the header differently now, in a way that demmt doesn't pick up
17:42imirkin_: Lyude: can you look into the tar ball upload thing? did you not use the release script?
17:42mattst88: so... no 1.0.14 tarball?
17:42mattst88: wow, what timing
17:45imirkin_: or perhaps Lyude is not a member of the x group... that was my issue when i released 1.0.13
17:45imirkin_: although i've since been added, i'm told
17:52karolherbst: mupuf: ohh no, it is getting worse :O I just did a "x == NULL" check in java :(
17:52mupuf: good good! Mouahahah
17:52karolherbst: somtimes I even od if(x) :D and then I wonder why that doesn't work
17:53imirkin_: karolherbst: i type "bool" a lot
17:53karolherbst: for some reasons I always use boolean
18:08joekamprad: WTH: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out
20:27karolherbst: imirkin_: time for some hitman debugging today?
20:31karolherbst: no crash within the benchmark
20:48karolherbst: mupuf: mhhh, I did something wrong regarding runpm... I triggered a dead lock somehow
20:57karolherbst1: and nouveau is gpu core bottlenecked
20:57karolherbst1: most likely
20:58karolherbst1: memory load is somewhere around 5%
21:10Jonimus: I just purchased a used laptop with a K3000M (GK104) chip in it, how is support for the chip progressing and how useable is it for a laptop with regards to things like powermanagment for battery life reasons?
21:37karolherbst: hum... the trace looks the same on intel/nouveau/nvidia and has the same issue
21:39karolherbst: Jonimus: is it a single GPU setup?
21:39Jonimus: karolherbst: no optimus.
21:39karolherbst: Jonimus: k
21:39karolherbst: Jonimus: kepler GPUs reclock without many issues on linux 4.10
21:40Jonimus: Its a Dell Preciosion M6700, more maybe is the M6800, I don't have it right in front of me at this second.
21:40karolherbst: and the GPU is usually off on an optimus setup if not in use
21:40Jonimus: Ok cool, I was able to do the DRI_PRIME=1 glxinfo and get the expected Nouveau output so that part appeared to work
21:41karolherbst: be aware, that you can't reclock through the pstate file as long as the GPU is turned off
21:41karolherbst: so best is to just reclock if you run something on it
21:41karolherbst: patches to fix this are in work
21:42imirkin_: karolherbst: so hitman works or what's the deal?
21:42imirkin_: or just doesn't cras?
21:42karolherbst: it doesn't crash
21:42imirkin_: well, i guess that's a start
21:42imirkin_: almost there ;)
21:42Jonimus: karolherbst: is there any auto reclocking or is that pretty much all manual unless I switch to the nvidia driver?
21:43Jonimus: It should default to lowest state on boot at least I assume?
21:43karolherbst: it defaults to the default state
21:43karolherbst: which means: no touchy
21:44karolherbst: imirkin_: you know what is odd? I see exactly the same issues on nvidia
21:44karolherbst: so it is an engine bug as it seems
21:44karolherbst: or I do something terribly wrong
21:45karolherbst: wanna take a look?
21:56imirkin_: not sure what i can do...
21:57karolherbst: mhh, there are some "37223: message: major shader compiler issue 3: 0:191(23): warning: `clipDistanceTemp0' used uninitialized" prints
21:57karolherbst: well, maybe we just miss an extension
21:57imirkin_: those warnings tend to be bogus.
21:57karolherbst: and otherwise the game does silly things
21:58karolherbst: maybe I should just export 4.5
21:58imirkin_: the used uninitialized thing doesn't recognize inout, iirc...
21:58imirkin_: clip distances are available starting GL 3.0
21:58karolherbst: yeah, but you know. They use 4.5 features
21:58karolherbst: maybe they just messed up
21:58imirkin_: how would that affect nvidia though?
21:59imirkin_: perhaps it cached something it shouldn't have, incorrectly?
21:59karolherbst: I replayed the apitrace on nvidia
21:59karolherbst: issue gone with 4.5
21:59karolherbst: ohh wait
21:59karolherbst: it's different
22:00karolherbst: no :( it's still thre
22:02karolherbst: okay, running the game with nvidia is fine
22:02karolherbst: so it's some odd path taking thing
22:02karolherbst: any idea how to debug this?
22:02karolherbst: maybe by using the nvidia GL_VENDOR?
22:04karolherbst: trace is here: https://drive.google.com/drive/folders/0B78S7GSrzebIemFQZlJyaExySlU
22:15karolherbst: imirkin_: before I annoy feral with super vague issues, we should try to figure out what they do wrong or so. Might be better this way
22:17imirkin_: replaying on intel...
22:18imirkin_: it's slow.
22:18karolherbst: okay, faking the GL vendor didn't help
22:18karolherbst: I think I should make a trace on nvidia as well
22:18karolherbst: maybe there will be an obvious difference
22:18imirkin_: unfortunately that'll use bindless, etc. (probably.)
22:19karolherbst: makes sense
22:19imirkin_: should write a wrapper that removes exts from their thing
22:19karolherbst: ohh wait
22:19karolherbst: I use primusrun :D
22:19karolherbst: I can just hack it in there
22:19imirkin_: does it render properly when run on nvidia?
22:20imirkin_: i assume that triangle towards the end shouldn't be there?
22:20karolherbst: and there should be a menu
22:21karolherbst: and the triangles inside the bar code loading animations are also wrong
22:21imirkin_: does it work on intel?
22:22karolherbst: mhh wait, faking the vendor... I did wrong
22:22karolherbst: something changed
22:22karolherbst: Mesa: User error: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound)
22:23karolherbst: GL ERROR :GL_INVALID_OPERATION : glFramebufferTexture2D
22:26karolherbst: I don't have your one tex patch