00:01imirkin_: we already compute all the stuff we need
00:01imirkin_: with scanInstructions()
00:01imirkin_: the other thing is just overhead =/
00:02karolherbst: well scanInstructions checks every instruction, right?
00:02karolherbst: I was just wondering if there is a way to not do
00:02karolherbst: sad :(
00:03imirkin_: among other things, we need it to lay out local arrays
00:07karolherbst: well this can be also done on the fly while generating the instsructions
00:07karolherbst: the only real reason to prescan the instructions is assignSlot, right?
00:08imirkin_: you have to know which arrays are accessed indirectly and which aren't
00:08karolherbst: mhhh, I see. In nir I already know that before
01:06misch: Good evening :)
01:10misch: Question GeForce GTX 660 nouveau on Debian Stretch - 3 monitor setup - screen starts corrupting when under load (watching video .., browsing image heavy web sites)
01:15karolherbst: misch: did you check if recocking the GPU helps out?
01:15karolherbst: I could imagine that memory can't keep up
01:15misch: karolherbst, Ups .. how would I do that?
01:16karolherbst: cat the file to see available states
01:16karolherbst: and echo the state name into that file
01:16karolherbst: last line is current state + power status
01:17karolherbst: but please save everything before doing it :)
01:17misch: 07: core 324 MHz memory 648 MHz
01:17misch: 0a: core 324-862 MHz memory 1620 MHz
01:17misch: 0d: core 549-1254 MHz memory 6008 MHz
01:17misch: 0f: core 549-1254 MHz memory 6008 MHz
01:17misch: AC: core 324 MHz memory 648 MHz
01:17karolherbst: depending on the kernel version your system might freeze
01:17karolherbst: or it might freeze nethertheless
01:17misch: LOL :)
01:17karolherbst: try echo 0f > /sys/kernel/debug/dri/0/pstate
01:17karolherbst: well, it is fairly safe on kepler GPUs
01:17karolherbst: but you never know
01:18misch: AC: core 1254 MHz memory 6007 MHz
01:18karolherbst: seems to have worked
01:19karolherbst: now try to put some load on the GPU again :)
01:19misch: Let me try ..
01:19karolherbst: but I could also imagine that with 3 displays the desktop is much smoother now anyway
01:20karolherbst: increasing the memory clock by 9x helps with quite a lot of things :)
01:20imirkin_: like tripping over yourself doing memory accesses :)
01:21misch: Now that I have started the BBQ .. where am I supposed to put my steaks? In other words ... what did that command do? Am I starting to burn something now?
01:21karolherbst: the GPU just runs at higher clocks
01:21imirkin_: the gpu should heat up, and your fans will spin up
01:21karolherbst: but still lower than nvidia
01:21misch: Great ..
01:22karolherbst: uhm... you don't seem to have boost levels
01:22karolherbst: well then you have the same clocks as nvidia :)
01:22karolherbst: check sensors for more infos
01:22karolherbst: "sensors" as in the cli command
01:23misch: So far .. so good. I had a nightmarish 3 days while trying to get amdgpu running ..
01:23karolherbst: misch: so the issues is less/gone now?
01:24karolherbst: well the GPU has some protections against overheating and Nouveau also does some basic stuff
01:24misch: karolherbst, Looks ago *so far* :) Before the adjustment, I started to get artifacts fairly fast after starting video.
01:25karolherbst: well you shouldn't get artefacts to begin with, but because I am out of ideas, this has to do
01:25karolherbst: and nvidia would probably clock the GPU up a little as well
01:25imirkin_: with 3 monitors, esp if they are large, you kinda need higher clocks
01:25karolherbst: misch: you could check if 0a instead of 0f also does the trick
01:25misch: Adapter: PCI adapter
01:25misch: GPU core: +1.19 V (min = +0.82 V, max = +1.21 V)
01:25misch: fan1: 1470 RPM
01:25misch: temp1: +45.0°C (high = +95.0°C, hyst = +3.0°C)
01:25misch: (crit = +105.0°C, hyst = +5.0°C)
01:25misch: (emerg = +135.0°C, hyst = +5.0°C)
01:25misch: power1: 39.54 W
01:25karolherbst: yeah, try 0a
01:26misch: Current temp seems to be ok though ..
01:26karolherbst: the voltage is quite high
01:26karolherbst: there is no load
01:26misch: There's 3 screens and a video running ..
01:26misch: In Firefox
01:26karolherbst: but if there is heavy load, the power1 values may go up to 120W+
01:27misch: I don't do heavy video (usually) - just a devlopment rig.
01:27karolherbst: should be still safe, because the GPU fans are scaled accordingly
01:27misch: Adapter: PCI adapter
01:27misch: GPU core: +0.88 V (min = +0.82 V, max = +1.21 V)
01:27misch: fan1: 1290 RPM
01:27misch: temp1: +41.0°C (high = +95.0°C, hyst = +3.0°C)
01:27misch: (crit = +105.0°C, hyst = +5.0°C)
01:27misch: (emerg = +135.0°C, hyst = +5.0°C)
01:27misch: power1: 21.25 W
01:27misch: with 0x0a
01:27karolherbst: that looks a bit nicer :)
01:28misch: It's unusally cold in South Tx - I can use the heat ;)
01:30misch: So .. I suppose I need to do that after every reboot?
01:40imirkin_: or boot with nouveau.config=NvClkMode=10
01:42misch: imirkin, I see. Thanks. No artifacts so far.
01:43imirkin_: (note that it's decimal there, while it's hex for the pstate file)
01:43karolherbst: you can also do 0xa for the module parameter
01:43misch: I got that :D
01:43karolherbst: but not a
01:43karolherbst: I think
01:44misch: I am using Linux since 0.94 .. wrote the first CDROM device driver. But what is going on with graphics in todays environment is a bit overwhelming ,,
01:45karolherbst: well it doesn't really help that GPUs are super complex
01:46karolherbst: Linus is already a little upset with us in general due to the size of the drm pull requests
01:46misch: karolherbst, Yes .. they are. But it's frustrating anyway. A kernel update on any other OS takes 10mins, Linux needs days.
01:47karolherbst: well depends on what you do when updating :)
01:47karolherbst: compiling everything indeed takes some time
01:47misch: karolherbst, I dealt with Linus 20yrs ago. He was *really* mean back than. ;)
01:47karolherbst: I heard stories
01:48karolherbst: the older you get the more "whatever" moments you get I guess
01:48karolherbst: even Linus isn't protected against that :D
01:48misch: Oh yeah. But I wasn't ready to give up on Linux just yet ;)
01:50karolherbst: good choice
01:51imirkin_: misch: GPUs are basically their own separate PCs which happen to be plugged into a PCI slot
01:51misch: But at some point I need the MSI Radeon 480 running. Or no more Oculus gaming for me. How is the GTX 1070 supported?
01:52imirkin_: you really want to stick to amd
01:52karolherbst: "people are working on it (tm)"
01:52imirkin_: they have a serious team behind their open-source drivers
01:53misch: I tried for 3 days to get the Radeon working. I have no errors or warning, firmware loaded all is well - but all screens are completely corrupted.
01:53imirkin_: all is well but nothing works - a common state for graphics, sadly
01:53misch: Obviously :(
01:53karolherbst: usually it is also safe to blame debian for using old software
01:53imirkin_: if you're willing to build foo-next kernels, hop over to #radeon, there will be people who can assist
01:54misch: I am monitoring #amdgpu .. pretty quiet there ;)
01:54imirkin_: dunno about that chan
01:54imirkin_: #radeon is the linux amd graphics chan
01:55misch: * #radeon :Cannot send to channel
01:55imirkin_: register your nick
01:55misch: LOL .. even their IRC is broken :D
01:56imirkin_: there's a very persistent jackass who spams all the graphics chans
01:56imirkin_: most have resorted to heavy-handed tactics such as this
01:56misch: So .. there's nothing new in IRC since 20 or so years?
01:56imirkin_: we're probably the only chan that hasn't
01:56imirkin_: mmmm ... well, this is someone who's actively doing it. hard to defend against that.
01:57imirkin_: i dunno what he has against graphics
01:57imirkin_: but he's been at it for about 10y or so
01:57imirkin_: this is also why *.ee tends to be banned in a lot of these chans
01:58mischmerz: Just changed my nick because the other one was registered
01:58imirkin_: by you 20 years ago? :)
01:59mischmerz: Quite possible. Though I went though 20+ email-addresses since then.
02:00mischmerz: /msg NickServ VERIFY REGISTER mischmerz kwsyppnbmjro
02:00mischmerz: ups :D
02:01imirkin_: esp when it applies to guns?
02:01imirkin_: [hey, you said you're from TX...]
02:02mischmerz: Yes I am. Though not born here. But I came as fast as I could ;)
02:02karolherbst: I thought no american is allowed to make jokes about guns :O
02:02mischmerz: LOL .. we take our guns seriously .. that's for sure. Where are you located?
02:05karolherbst: not in the US
02:07mischmerz: Based on your name .. I'd say Slovenia .. or Hungary.
02:07karolherbst: close enough
02:08imirkin_: (yeah, americans are bad at ethnic profiling based on name)
02:09karolherbst: well my forname is pretty much east european anyway, I don't know in which country of those it doesn't exist
02:09mischmerz: Hmm .. as I am able to speak German .. as is Karol ..
02:09imirkin_: your last name couldn't be slavic though
02:10mischmerz: I should have check Twitter before asking ..
02:10mischmerz:slams her head on the table ..
02:10karolherbst: how does that help?
02:10karolherbst: ohh right
02:11karolherbst: allthough my location there really doesn't help
02:11mischmerz: The pain gives a new perspective.
02:11karolherbst: or maybe it does
02:11karolherbst: I get the feeling that joking about the term "cyber" is really just common in germany... allthough others seem to adapt quite fast now :)
02:15mischmerz: Haven't been in Germany for a few years.
02:15mischmerz: I miss Gehacktes-Brötchen :(
02:15karolherbst: I don't
02:16mischmerz: Peeps here aren't even able to make a good rotisserie chicken.
02:17karolherbst: well I don't live in germany anymore anyway, but I just moved to a country nearby
02:17mischmerz: Belgium .. I know ..
02:18mischmerz: Rats ;)
02:18mischmerz: But doesn't matter anyway. A little mystery here and there makes things more interesting.
02:18karolherbst: imirkin_: arb_tessellation_shader 1730/1730 :)
02:20karolherbst: now that annoying geometry shader bug is still left :(
02:24karolherbst: imirkin_: is there maybe some special handling needed for empty vertex shaders?
02:28mischmerz: karolherbst, Thanks for following ;) Lot's of ranting lately :D
02:40mischmerz: Everything looks still fine ..
03:45mischmerz: Quick question - does it make a difference for the GPU driver if it's running 32bit/64bit? Someone suggested that my amdgpu troubles may be a result of me (foolishly) installing 32bit Debian
03:45karolherbst: nobody tests on 32bit
03:46karolherbst: well except a few users
03:46karolherbst: but I am sure all devs are working on 64 bit systems
03:46mischmerz: Why in the living hell did Debian call their 64bit distro AMD_64? Jeez ..
03:46karolherbst: if you are a careful dev, it shouldn't matter
03:46karolherbst: mischmerz: because it is a CPU extension called AMD64 :)
03:47imirkin_: coz it's the 64-bit instruction set by amd?
03:47karolherbst: intel tried to push IA-64 but somehow failed with that
03:47imirkin_: 32-bit should not be expected to work with modern software
03:47mischmerz: karolherbst, nouveau performs beautifully now. Thank you for your work. All of you.
03:47imirkin_: no one tests, applications assume infinite memory, etc
03:48imirkin_: at the very least, you should use a 64-bit kernel, even if you want 32-bit userspace
03:48mischmerz: uname -r 4.9.0-5-686-pae
03:48imirkin_: yeah, so pae is the worst of all world
03:49imirkin_: but it's a necessary evil for >4gb on 32-bit
03:49imirkin_: however everything will basically not work with it :)
03:49mischmerz: Didn't play back the 400Gigs of backup yet. So I re-install tomorrow. What else can one do on a Sunday?
03:49imirkin_: esp if you have the 64gb variant of pae
03:50karolherbst: imirkin_: any ideas where I could look as well for differences regarding the geometry shader errors?
03:50imirkin_: you could summarize the issue and ask me...
03:51karolherbst: well, shaders are equal, headers are equal, info struct is equal, but vertex ID outputs are all 0
03:51imirkin_: "vertex id outputs"?
03:51karolherbst: "Expected vertex IDs: 1 2 3 4" "Actual vertex IDs: 0 0 0 0"
03:51imirkin_: and where does that come from?
03:52karolherbst: glMapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER, GL_READ_ONLY)
03:52imirkin_: so the *most likely* explanation is ... TF is messed up
03:53karolherbst: I have two failing TF tests as well
03:53karolherbst: ohh wait, a few more actually
03:53karolherbst: yeah okay, will look into those first then
03:54karolherbst: but I don't see how those fails will give me any more informations than the one I was looking at :(
03:59imirkin_: look at the TF config
03:59imirkin_: it has to be carefully matched to the shader outputs
03:59imirkin_: iirc the outputs in your example are totally different
03:59imirkin_: which isn't a problem in and of itself
03:59imirkin_: but it has to match the TF settings
04:00imirkin_: and my guess is that this wasn't hooked up for GS
04:01karolherbst: for the vertex shader: nir->info.has_transform_feedback_varyings true
04:02karolherbst: I see
04:02karolherbst: well for the geometry shader this flag is also set to true
04:03imirkin_: sounds wrong
04:03imirkin_: only GS should worry about TF
04:03karolherbst: in general?
04:04imirkin_: in general, only the last pre-rast stage in a pipeline worries about TF
04:04imirkin_: i.e. GS, TES, VS in that order
04:05karolherbst: well the comment says: "Was this shader linked with any transform feedback varyings?"
04:05imirkin_: yes, and TF varyings can only be on the last pre-rast stage :)
04:05karolherbst: I see
04:05imirkin_: anything that happens before is invisible to TF (unless a later shader passes it through of course)
04:06imirkin_: so in this case, only GS outputs are available for TF
04:06imirkin_: if you only had a VS, then VS outputs would be available for TF
04:06karolherbst: ahh, I see
04:06karolherbst: I assume this is all transparent to the shaders/compiler stuff?
04:07imirkin_: the pipeline goes VS -> (TCS -> TES) -> GS -> rast -> FS
04:07karolherbst: more or less
04:07imirkin_: TF happens at the rast boundary
04:07imirkin_: so whatever the stage before that is, that's what gets linked to the TF config
04:08karolherbst: I guess it makes sense to take a look at nvc0_program_create_tfb_state then
04:08karolherbst: or is there something else I should check?
04:09imirkin_: i recommend trying to understand the TF stuff, at least its purpose :)
04:09imirkin_: the literal config can be ... tricky
04:09imirkin_: and definitely don't look at the nv50 tf code
04:09imirkin_: that engine is simultaneously too configurable and not configurable enough :)
04:13karolherbst: imirkin_: what is this pso->output[i].stream thing?
04:14imirkin_: can emit vertices to one or another stream
04:14imirkin_: a TF config can capture vertices from a specific stream
04:14imirkin_: note that multiple streams is only supported for points in unextended GL
04:14imirkin_: [and nvidia hw]
04:15imirkin_: and also streams > 1 are never rasterized
04:15imirkin_: [in unextended gl and nvidia hw]
04:15karolherbst: I am wondering, because I now dumped the nvc0_transform_feedback_state object and with nir the stream member is set to 0, where with TGSI I get stream = "\000\373\263"
04:16karolherbst: uhm wait a second
04:17karolherbst: with TGSI it is called after the vertex and after the geometry shader, where with NIR it is only called after the vertex one
04:22qybnwd: ▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 dljywxzzy: sarnex kbidarka Kabouik_ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
04:29titsJIMYVF: ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 twpxqmddim: gn mithro alexxy ▄▄▄▄▄▄▄▄▄,
04:29titsJIMYVF: ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 ptkkjivnd: mooch2 ajmitch Moiman ▄▄▄▄▄▄▄▄
04:29titsJIMYVF: ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 kdwocbdwv: funnel vedranm glisse ▄▄▄▄▄▄▄▄▄
04:29titsJIMYVF: ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 wzmix: glisse_ udoprog rhyskidd ▄▄▄▄▄▄▄▄▄▄▄▄▄
04:34imirkin_: streams should only be set when doing multi-stream stuff... which is never
04:35mischmerz:listens to "Má vlast" .. DSD on Linux :D
04:42imirkin_: which one's that?
04:42imirkin_: good call.
04:42karolherbst: no idea if that works
04:42imirkin_: does that block the messages, or just strip them out?
04:42karolherbst: "+c - No color. All color codes in messages are stripped."
04:42imirkin_: did that come out colored?
04:42karolherbst: negative testing
04:43karolherbst: try again
04:43karolherbst: don't use dark blue pls
04:43imirkin_: i'll switch to black then
04:43karolherbst: I hope that works :)
04:43karolherbst: and stays
04:43imirkin_: won't stop that one from posting the hate content
04:44imirkin_: mmm... you can probably use chanserv flags
04:44karolherbst: mlock stuff
04:44imirkin_: in any case, it's not like this chan empties otu
04:44karolherbst: freenode is.... weird
04:45karolherbst: imirkin_: I don't have enough rights to do that
04:46karolherbst: skeggsb: do a "/msg ChanServ SET #nouveau MLOCK +c" pls
04:46imirkin_: only skeggsb and marcheu
04:47karolherbst: but without those colors those spam bots are less annoying already
09:44lmnts: what is the best card for Nouveau and does it support the LTS kernel?
12:47liamdawson: I remember talking to someone here previously about kernel issues when swapping between dGPU and iGPU on Dell XPS devices with the GTX10xx series... If I recall correctly, the solution (for now) is to override the ACPI Rev, right?
12:47liamdawson: Also, anything I can watch to see when the issue is resolved?
14:12imirkin: lmnts: what are the parameters for 'best', i.e. what makes one board better than another? also, which kernel is 'the LTS' kernel?
15:04lmnts: imirkin, since it is unofficial maybe there is non-linear performance variations between cards and line of cards. what gets me the most bang for buck? is the 1080ti the most powerful consumer card for linux? 4.9.75-libre-lts is my kernel
15:05imirkin: "bang for the buck" is a tough question. in any case, any Kepler board will work reasonably well. iirc 4.10 actually had a bunch of fixes for kepler reclocking, so with 4.9 it'll still be suckier-than-it-needs-to-be.
15:05imirkin: so you're looking at the GTX 6xx/7xx series (but not 750)
15:08lmnts: i have seen other people also recommending the 7xx series. the Pascal cards had no comments on them. why not them? imirkin
15:09imirkin: coz they'll work like molasses
15:10imirkin: they boot up at maybe 1/10th the max clocks, and there's no way to change that
15:10imirkin: so ... yeah. not great.
15:10imirkin: on top of that, there are a bunch of known bugs on maxwell+ that i've never gotten around to fixing
15:11imirkin: largely because it's difficult to care about such locked-down hw
15:11lmnts: it's a shame :| i learned today you need a kernel driver to even use 3D acceleration on AMD cards
15:11imirkin: also if the 'libre' in the kernel version refers to the linux kernel with request_firmware() ripped right out of it, you're SOL for using any GTX 950+
15:12karolherbst: lmnts: well, you need a kernel driver for nearly everything
15:12imirkin: you need a kernel driver to enable userspace to access hw.
15:12imirkin: at least in modern protected-mode operating systems.
15:12imirkin: DOS was a lot more fun :)
15:13lmnts: i meant a blob
15:13imirkin: want to overwrite the interrupt table? go right ahead!
15:13karolherbst: it was a different world back then :(
15:13imirkin: everything needs blobs
15:13imirkin: we're in a blobby world
15:14imirkin: anything past like ... G98 needs some kind of data to even operate, passed in from the CPU
15:14lmnts: at least now that more people care about it we can see some change
15:14karolherbst: yeah, towards more blobs
15:14karolherbst: it is getting worse, not better
15:14imirkin: you, however, appear to be making a difference between "blog that's written by nouveau project members" and "blob written by nvidia employees"
15:15karolherbst: well our blobs are open source
15:15imirkin: still blobs
15:15imirkin: some piece of data
15:15imirkin: which is compiled by some tool
15:15imirkin: and that the kernel has to send to the gpu in order for it to operate
15:15lmnts: so not inherenty evil imirkin ?
15:15lmnts: only the closed ones
15:16imirkin: how do you distinguish what's open and what's closed?
15:16imirkin: what makes the ones written by nouveau project members any more open than the ones written by nvidia employees?
15:16lmnts: you can sign the code
15:17imirkin: actually code signing is the reason that you won't be able to use GTX 950+ :)
15:17imirkin: the gpu requires the code to be signed by a key not available to us
15:17lmnts: signing as in you show the code and then verify that the binaries match what the end user gets
15:18karolherbst: well then the driver would have to verify it
15:19karolherbst: but in the end our firmware is open source and everybody can do whatever it wants with it, it even contains symbol names and comments, so it is easier to understand what it does
15:19karolherbst: now arguing with what exactly open source code helps would be tiring
15:20karolherbst: regarding security people kind of agreed upon that open source code is better than closed ones, because research is much easier and some even say that finding bugs is easier
15:24imirkin: so ... if you want to make it harder for people to find bugs in your shit, make sure it's closed code?
15:24imirkin: that line of reasoning is what leads to the current situation :)
15:25lmnts: so how is it getting worse if open source is growing?
15:25imirkin: karolherbst: did you give DOW3 + bindless a shot? if not, i'll just push
15:25karolherbst: I planed to do so today
15:25imirkin: it's a little different.
15:25lmnts: and RISC-V
15:26imirkin: coz apparently people need a whole separate library to left-pad a number.
15:29karolherbst: imirkin: did you look into those hitman issues with bindless btw?
15:43karolherbst: imirkin: is bindless used by default with Dow3 or do I have to enable it somehow?
15:50imirkin: DOW3 requires it
15:51imirkin: i didn't look at the hitman issues, but they weren't bindless-related
15:51imirkin: i mean - i looked only very briefly
15:51karolherbst: well DOW3 runs without graphical issues
15:51karolherbst: it is just terribly slow
15:52karolherbst: or at least nothing which stands out
15:52imirkin: no crashes/etc?
15:52imirkin: no giant memory leak
15:52imirkin: or ... who knows
15:52karolherbst: I did run the benchmark and I let it run for 1-2 minutes
15:52imirkin: is it supposed to be slow on your hw?
15:52imirkin: (i.e. what are the requirements)
15:52karolherbst: I look them up
15:53karolherbst: min: 1GB Nvidia 650Ti 1GB
15:53karolherbst: rec: 4GB Nvidia 980Ti
15:53karolherbst: well terribly slow meant like 10-20 fps
15:53karolherbst: so I guess it is "good enough"
15:54imirkin: my benchmark was pegged at 12.5fps, which i think means "lower than the lowest measurable amount"
15:54karolherbst: mhh weird
15:54imirkin: i've seen that in a few games
15:54imirkin: that obviously run at like ... 5 seconds per frame
15:54karolherbst: well let me check the settings again
15:55karolherbst: since intel added those prime syncing stuff, everything not running at 60 fps feels slow anyway :/
15:56imirkin: well it's a heavy game i guess
15:56karolherbst: uhh image quality was maxed out
15:56imirkin: and you probably weren't running it in a 1200x800 window
15:56karolherbst: full hd with image quality at max :D
15:57karolherbst: on low it feelts much better
15:57imirkin: k :)
15:57karolherbst: 25 fps in the menu
15:58karolherbst: will run the benchmark a few times
15:59karolherbst: avg fps 20.78
15:59karolherbst: could be better
16:07karolherbst: imirkin: are there bindless piglit tests?
16:08karolherbst: nvidia avg fps: 28,86
16:09imirkin: karolherbst: yes
16:09imirkin: but hardly complete
16:09karolherbst: I see
16:09karolherbst: well you get my okay regarding the bindless stuff
16:09karolherbst: didn't look at the patches though
16:11imirkin: i was more looking for testing on a beefier gpu than mine
16:11imirkin: since multiple SMs sometimes fight, etc
16:11imirkin: thanks for doing that :)
16:12karolherbst: well after you push those, I kind of feel like having to support bindless with nir as well :)
16:12imirkin: (all my gpu's are single-SM... except some teslas which this doesn't apply to)
16:12imirkin: or MP? i can never remember the teminology
16:12karolherbst: ohh right.. Tom^ we need to talk :p
16:13imirkin: pretty sure gk106 should be "big" by comparison
16:13karolherbst: but still small
16:14karolherbst: but mine is one with 5 SMX
16:14karolherbst: so the biggest one
16:14Tom^: karolherbst: that sounds serious.
16:15karolherbst: I need that 780 ti for testing stuff
16:15Tom^: adress and il send it tomorrow!
16:15karolherbst: I will discuss the details this week and give you some infos on how to ship it
16:15Tom^: sure thing
16:16karolherbst: I just need to figure out what problems your GPU has with the nvidia driver
16:16Tom^: yeah, havent investigated much. i lack the skills and patience for that.
16:17karolherbst: imirkin: well the patches look all okay. Are there any patches for non kepler gens?
16:17karolherbst: I have no idea what is missing to support it for maxwell
16:17imirkin: images are done with TICs on maxwell
16:17imirkin: so ... just have to change the image handle func
16:18karolherbst: I see
16:21imirkin: but should be pretty straightforward
16:21imirkin: mostly it needs testing
16:21imirkin: i can write the patch
16:21imirkin: nothing uses bindless images though, afaik
16:21karolherbst: well I can test with my pascal GPU
16:21imirkin: so beyond piglit there's not much to do
16:22karolherbst: allthough I doubt there are deqp tests for this
16:22imirkin: afaik no
16:22karolherbst: but CTS for sure
16:22karolherbst: well at least for bindless_texture
16:22imirkin: why 'for sure'?
16:22karolherbst: it seems like there are tests for pretty much everything in it
16:22imirkin: it's not core functionality
16:23karolherbst: they test a lot of extensions as well
16:24karolherbst: mhh, they have some EGL tests for gl_nv_bindless_texture and gl_img_bindless_texture
16:25karolherbst: but just testing the proc address
16:25karolherbst: so this is pointless
16:26karolherbst: imirkin: there are tests for GL_ARB_parallel_shader_compile in the CTS for example
16:26karolherbst: which isn't core as well
16:26imirkin: yeah, there are some
16:26imirkin: that's probably like a 1-line test
16:26imirkin: bindless is ... harder.
16:34imirkin: found a little bug on review. only affects images though.
16:35imirkin: - screen->img.entries = (void *)screen->tsc.entries + NVC0_TSC_MAX_ENTRIES;
16:35imirkin: + screen->img.entries = (void *)(screen->tsc.entries + NVC0_TSC_MAX_ENTRIES);
16:35karolherbst: shouldn't matter, should it?
16:36imirkin: pretty sure it should
16:36imirkin: entries is in pointer units
16:36imirkin: (void*)foo + 1
16:36imirkin: means add 1 to the pointer value foo
16:36imirkin: foo + 1 means add 1 unit of *foo to the pointer value foo
16:37karolherbst: uhm... (void *) doesn't give you the address of foo
16:37imirkin: if screen->tsc.entries were void * it wouldn't matter
16:37karolherbst: or does it?
16:37imirkin: but it's void **
16:37imirkin: think about it.
16:37imirkin: struct foo *bar = ...;
16:37imirkin: what's "bar + 1"?
16:38karolherbst: mhh, I kind of always avoided to write code like this, because it just looks like bad style doing something like that :)
16:38imirkin: but what does it do?
16:38karolherbst: I would have to guess
16:39imirkin: it's the same thing as &bar;
16:39karolherbst: weird, but okay
16:39imirkin: void* is special (and not legal C, technically), where it's treated as char* for pointer math purposes
16:39karolherbst: I see
16:39imirkin: (rather, void* is legal. pointer math with void* isn't)
16:40imirkin: and yeah, you can scream "bad code" but ... it's all well-defined and people are used to seeing it
16:56Tom^: i wonder if clang allows it, might be a thing to check. compiler compatibility isnt so bad :P
16:57Tom^: i know gcc does as long as you dont run with -pedantic-errors
17:02herrdeh: Hello, somebody around who wants to assist with a hibernate/resume problem?
20:38karolherbst: imirkin: can you run unigine heaven on Quality Ultra and tess moderate and tell me if you also see some missrenderings?
20:38karolherbst: on maxwell
20:38karolherbst: ohh wait, do you even have a maxwell GPU?
20:39karolherbst: I think you said you didn't
20:39karolherbst: nvm then
20:44karolherbst: realisticrendering runs with nir :)
20:48imirkin: on maxwell it's known
20:48imirkin: esp unigine valley
20:48imirkin: but iirc heaven too
20:48imirkin: maxwell is misrendering-galore
20:48imirkin: ST_DEBUG=flush fixes it
20:48imirkin: which means we're not flushing some cache of some sort at some time
20:51karolherbst: well, at least I am happy to see the same bugs with tgsi and nir :)
20:51imirkin: yeah, it's some resource management issue
21:42karolherbst: imirkin: regarding 64bit types: I have to create splits after a 64bit ops and a merge when consuming that value, right?
21:50imirkin: and i'd recommend starting them out with 2 values which are merged.
21:53imirkin: i.e. every 64-bit lvalue should either have a def that's a merge
21:53imirkin: or have a lone consumer that's a split
21:54karolherbst: and I assume both is also fine
21:55karolherbst: uhm wait
21:55karolherbst: in that case it would be two values instead of one
21:55karolherbst: okay yeah, I see
22:07karolherbst: imirkin: what about stuff like that? "mov u64 %r102d 0xc000000000000000"
22:09susan34: how to know the first version supporting GP108 3d acceleration please ? i found that GP108 is NV138. and according to the matrix, 3d looks supported, but i get NOUVEAU(0): Error creating GPU channel: -19
22:10karolherbst: susan34: might be some other bug
22:10karolherbst: susan34: please paste the full dmesg output somewhere and share the link
22:10susan34: ok. might it be a file (like a firmware) missing ? i found no "xxx no such file or directory"
22:11susan34: thanks. dmesg : https://pastebin.com/k75S1YSW
22:11imirkin: karolherbst: can't have that.
22:11karolherbst: imirkin: so I need to split that as well
22:11imirkin: karolherbst: yep.
22:11imirkin: karolherbst: or merge it :)
22:11susan34: xorg.log : https://pastebin.com/kcrnDjrp
22:11imirkin: i.e. if it's an immediate, you can just move it to 2 values, and then merge.
22:12imirkin: susan34: accel has only been added recently for GP108
22:12imirkin: i don't think it's upstream anywhere yet
22:12imirkin: susan34: you'll need to grab nouveau from https://github.com/skeggsb/nouveau/commits/master
22:12imirkin: and make sure to get updated linux-firmware
22:14karolherbst: ohh, that bad actually, troublesome
22:14susan34: i've XDRIVER_XF86_VIDEO_NOUVEAU_VERSION = 1.0.15 ; it looks like the last one.
22:14susan34: oh, ok, from the git. thanks.
22:15karolherbst: yeah, the ddx doesn't matter much
22:15susan34: thanks a lot for these information
22:15imirkin: the kernel driver from git
22:16imirkin: ddx 1.0.15 should be fine