02:34 imirkin: skeggsb: probably good to merge this in: https://patchwork.freedesktop.org/patch/249356/?series=49652&rev=1
02:34 imirkin: i spent a bunch of time trying to figure out why i couldn't get atomic to work -- turns out because the NV34 probed last.
02:35 imirkin: [for some reason i don't have that patch in my email, dunno why - weird.]
02:41 skeggsb: yer, i'll grab it
02:45 imirkin: thanks
02:49 imirkin: btw - what do you think about dumping all the alpha formats from overlays?
12:25 rhyskidd: pendingchaos: what is the status of any followup bindless series (re: https://patchwork.freedesktop.org/series/44369/)
12:26 rhyskidd: i noticed some piglits try to execute IMG2HND and SAMP2HND from tgsi, which fails in nvir
12:26 rhyskidd: as nouveau doesn't lower them
12:37 karolherbst: rhyskidd: we can't lower them
12:38 karolherbst: or not really
12:38 rhyskidd: hrmm, okay at the moment the debug builds assert on that
12:39 karolherbst: mhh, I kind of don't like how the patches look like anyway
12:39 karolherbst: it unnecessary magic
12:39 karolherbst: *adds
12:40 rhyskidd: like so: https://paste.fedoraproject.org/paste/ImTUk1iNwuJKn~yrkJ2miQ
12:40 karolherbst: the 2HND opcodes shouldn't be TexInstructions
12:41 karolherbst: I don't see the benefit of doing it this way
12:43 karolherbst: "glsl_to_tgsi: allow bound samplers and images to be used as l-values" is also kind of the wrong approach. the l-value is neither bound nor bindless, it's both.
12:45 karolherbst: but the entire extension is a bit sucky here
12:45 pendingchaos: IIRC I accidentally wrote "l-value" instead of "r-value" when sending out the patches btw
12:45 karolherbst: you don't want to add the SAMP2HND instructions if all assignments to the variable are bound, eg.
12:45 karolherbst: ahh
12:46 pendingchaos: well not IIRC anymore, I just found my reply to the email mentioning the mistake
12:47 karolherbst: I am not quite sure if we want to rely on backend compilers to optimize *2HND operations away if we don't need them
12:48 karolherbst: heh, is patchwork down?
12:48 karolherbst: ahh, works again
12:50 karolherbst: pendingchaos: correct me if I am wrong, but whenever you do "some_func() { sampler2d_t samp = in_samplers[0]; texture*(samp, ...); }" you would end up with a SAMP2HND instruction, no?
12:54 imirkin: iirc that's the only reasonable way to go
12:55 karolherbst: but the sampler is bound
12:55 imirkin: doesn't matter.
12:55 karolherbst: and all assignments are bound
12:55 imirkin: how do you distinguish that from
12:56 imirkin: sampler2d_t samp = x ? in_samplers[0] : bindless_sampler_var;
12:56 karolherbst: if it's not decided that all assignments are bound then it's bindless, sure
12:56 karolherbst: I am just thinking about the case where it's decided
12:56 imirkin: AND iirc with bindless, even a "bound" sampler can be assigned a bindless handle.
12:56 karolherbst: how?
12:57 karolherbst: ohh, maybe out vars
12:57 karolherbst: ...
12:57 karolherbst: yeah.. that might actually work
12:57 karolherbst: but then you assign to a bindless handle and have to convert anyway
12:57 imirkin: just like a regular sampler
12:57 imirkin: i.e. uniform sampler2D foo;
12:58 karolherbst: well you can't assign anything to foo, can you?
12:58 imirkin: and then you do glUniformHandleui64(location-of-foo, the-handle)
12:58 imirkin: so it's "bound", but kinda-bindless
12:58 karolherbst: anyway, I am not arguing that there are cases where we can't skip the conversion
12:59 karolherbst: but about the cases where we know for sure it's bound
12:59 imirkin: without bindless, you can't have sampler l-values
12:59 imirkin: so if you see a sampler l-value, you know that bindless is probably involed
12:59 karolherbst: sure, but still, you can know at compile time that this l-value only ever have bound samplers assigned
13:00 imirkin: maybe
13:01 karolherbst: and we can agree that for a "sampler2d_t sampler = bound_sampler; texture2D(sampler, ..);" it is quite easy to decide
13:01 karolherbst: sure, we can just agree to not care about it as it won't ever happen
13:02 karolherbst: but then we can also just not care about all the bound+bindless handles inside the same shader, as afaik this doesn't happen anyway
13:41 Alec: karolherbst: what will happen to the compiler? I came across one recently that segfaulted (so yeah, please don't do that) - is it nonsense, or fine, or...?
13:42 Alec: But yeah those are some iffy semantics.
13:44 Alec: Actually - I may need a pen later. This brings back memories.
16:08 endrift: So I figured out why I thought I couldn't render to integer textures, which I might have mentioned here a few days ago
16:08 endrift: turns out the Intel driver doesn't like rendering to *unsigned* integer textures
16:08 endrift: is that a general thing or just the Intel driver?
16:08 endrift: (will ask in #dri-devel if people here don't know)
16:09 Alec: Let me know the answer please. Because I'm surprised it cared/knew
16:10 endrift: (This was i915 fwiw, not iris)
16:12 imirkin_: endrift: that is not a thing (at least not in GL)
16:12 endrift: what, unsigned integer textures?
16:12 imirkin_: depending on the generation, intel does have various funny business with int vs uint
16:12 imirkin_: no, i mean not being able to do it
16:13 endrift: oh ok
16:13 imirkin_: also you might be declaring an output as int but binding a uint texture to it? then it could get upset.
16:13 endrift: this is gen 9.5 I think
16:13 imirkin_: yeah, it's all pretty regular by then
16:13 endrift: no I was outputting uvec I'm pretty sure
16:13 imirkin_: gen6 has funny business iirc
16:13 endrift: hmm
16:13 endrift: it's an 8750H so I'm pretty sure that's gen 9.5
16:14 endrift: maybe 9
16:14 imirkin_: not to say bugs don't exist
16:14 imirkin_: but at the GL level, that's definitely fine
16:14 imirkin_: if you have a repro, go to #intel-3d (iirc)
16:14 imirkin_: even like an apitrace of your program
16:14 imirkin_: which demonstrates the fail
16:14 endrift: let me check if I have an apitrace still
16:14 endrift: I may
16:41 imirkin_: endrift: i'm on a intel gen9 here, in case you want a second opinion.
16:41 endrift: I'm trying to change my textures to ui to see if it works
16:42 endrift: I may have been using RED16UI or something weird like that, I forget
16:42 imirkin_: should be fine...
16:42 imirkin_: you mean GL_RED_INTEGER + GL_R16UI
16:45 endrift: yeah that
16:50 endrift: hmm no that worked
16:50 endrift: I tried changing everything back to RGBA8UI
16:50 endrift: apart from one bug it introduced there were no problems
16:50 imirkin_: sounds like there's more to it then :)
16:50 endrift: yeah, I didn't look too hard into it before
16:50 endrift: maybe I should have
16:51 imirkin_: perhaps you were getting clamping somewhere you didn't expect?
16:51 endrift: for all I know it was me forgetting to use GL_RGBA_INTEGER
16:51 imirkin_: that'd cause an invalid texture
16:51 endrift: exactly
16:51 imirkin_: and a GL error
16:51 imirkin_: you should look at those :)
16:51 endrift: I was getting a GL error
16:51 imirkin_: haha
16:51 endrift: I usually do but at that point I was more trying to get anything working so I just reverted it
16:51 imirkin_: "must be a bug in the driver", right?
16:52 endrift:shrugs
16:52 imirkin_: :p
16:52 imirkin_: unless it happened on nvidia, in which case it's a bug in your application
16:52 endrift: the error I was getting was something about "Intel doesn't support" ... etc
16:52 Alec: Or you should pay for Cuda and using your GPU in a different shaped box
16:52 endrift: which is why I thought that in the first place
16:53 endrift: I'm a little surprised I don't still have an apitrace floating around
17:09 imirkin_: endrift: huh, that's surprising. most likely it was a perf warning
17:09 imirkin_: like uint tetxures don't support fast-clears or something
17:09 endrift: could have been
17:10 imirkin_: you'll usually see those when replaying an apitrace
17:10 imirkin_: but they're not GL errors
17:10 endrift: actually I am getting that warning with signed int textures
17:10 endrift: yeah I understand that now but I didn't when I started on this
17:10 imirkin_: they're just like fyi's about doing something that's not the most performant on that hw
17:10 imirkin_: there are also warnings like "you bound an incomplete texture here, so you'll get all black"
17:11 imirkin_: which is legal to do in GL, but in practice every time it happens is an error
18:41 Lyude: rhyskidd: ooooh, just noticed your patch series with the INIT_RESET_* stuff. Very interesting, I'll try to test it out today on my nvidia GPUs
19:39 imirkin_: Lyude: you've played with igt, right?
19:39 Lyude: imirkin_: yep
19:40 imirkin_: and what about modetest?
19:40 Lyude: it probably doesn't work on nouveau
19:40 Lyude: iirc
19:40 Lyude: why are you asking?
19:40 imirkin_: i'm looking for an independent opinion of whether it'd be interesting to integrate modetest-like functionality into igt
19:41 imirkin_: also if i can't land my current modetest patchset, i'm just going to start my own project
19:41 imirkin_: half those patches have been pending for 2y...
19:41 Lyude: imirkin_: can you show me the patch series?
19:42 imirkin_: i sent it to dri-devel yesterday, but also accessible here: https://github.com/imirkin/drm/commits/formats
19:43 airlied: imirkin_: you could just push them
19:43 airlied: forking seems a bit drastic if you can just push anyways
19:43 Lyude: errr, we kind of ask that people get reviews first nowadays
19:43 imirkin_: airlied: well it wouldn't be a fork. more like a "new repo for useful kms tools"
19:43 Lyude: but i'm happy to look at this
19:44 imirkin_: since tbh it doesn't really seem like modetest really belongs as part of libdrm
19:44 airlied: imirkin_: maybe move it to igt :)
19:44 imirkin_: the binary doesn't get shipped anywhere either
19:44 imirkin_: airlied: that's what danvet suggested. i was hoping to get an independent opinion of whether that sort of time investment made sense.
19:46 danvet: imirkin_, I'm just suggesting that maybe pooling in igt is better long-term
19:46 danvet: but also, tests/tools in libdrm won't go away so whatever
19:47 imirkin_: don't get me wrong -- i'd love to not have to write these tests ;)
19:47 danvet: it just doesn't help that we have split tests for something that's supposed to work across drivers
19:47 Lyude: i agree with danvet on this btw ^
19:47 danvet: in reality kms is decidedly not-so-cross-vendor :-/
19:47 imirkin_: i just got the impression that the current stuff wasn't usable for me
19:47 danvet: well it isn't great
19:47 imirkin_: since i need less of a test and more of an exploration tool
19:47 danvet: that's kinda the point
19:47 danvet: ah you mean igt
19:48 danvet: we do have tools in igt
19:48 imirkin_: fixing up modetest isn't so difficult
19:48 danvet: so maybe just moving that over would help
19:48 imirkin_: it's just annoying to have to keep carrying patches locally
19:48 danvet: but you can also stuff things into igt tests themselves
19:48 danvet: yeah I mean just push, the thing wont die anyway :-)
19:48 danvet: well, need to get some acks or something like that for libdrm
19:49 imirkin_: well, review is nice. e.g. ville pointed out that my change would mess up intel's LUT (the way i was originally doing it)
19:49 danvet: imirkin_, trouble already is that noveau got the 30bpp stuff backwards compared to others, so not cheering more nouveau-only stuff
19:49 imirkin_: danvet: you mean nvidia, not nouveau :p
19:49 danvet: that's why I'd like to see more igt
19:49 danvet: well, we have fourcc for all of them
19:50 imirkin_: and we support the ones that the hw supports
19:50 danvet: and yeah you can't express that with the old addfb1
19:50 imirkin_: which is the whole problem :)
19:50 imirkin_: (since there was basically no addfb2 userspace until fairly recently)
19:51 danvet: well, would need more common stuff and common tests/tools :-)
19:52 danvet: but everyone just loves to have their own thing
19:52 danvet:ranting
19:53 imirkin_: yes. everyone should drop THEIR thing and use MY thing. ;)
19:53 airlied: moving all tests out of libdrm to igt should be a goal
19:53 airlied: or moving libdrm to igt :-p
19:54 Lyude: i mean to be fair, half the time I don't even know where all of the relevant dev tools for a certain GPU driver are if I don't touch whichever driver is in question often, that is pretty painful and wastes time.
19:54 Lyude: which is why i'm at least for moving as much as possible into igt
19:54 Lyude: it would be very nice to be able to just look in a single directory and go "ok, here's all of the tools"
19:55 imirkin_: so like ... i'm looking at the current tests list... obviously not a detailed analysis, but i don't see anything that tests every advertised fb format
19:59 danvet: format_desc_struct in lib/igt_fb.c is the current list of things we support in the test lib
19:59 danvet: iirc there's a pile of tests that walk through all the ones you claim to support
20:00 danvet: bigger issue probably lack of crc support
20:00 imirkin_: ah ok. a couple i looked at didn't seem like it, but it was a very quick look-through
20:00 Lyude: imirkin_: btw, if we could get more formats in igt_fb.c (particularly the ones that nouveau uses) that would enable a pretty large number of tests
20:00 imirkin_: yeah, no crc which means some kind of human-interaction for "does this look right"
20:00 danvet: I think mlankhorst and mkahola have done most of the work in this area recently
20:00 Lyude: i'm wondering how much of this modetest work could go into there
20:00 danvet: especially adding all the yuv stuff
20:00 Lyude: also: DP monitors with CRC...?
20:00 danvet: Lyude, we tried and cried
20:00 danvet: for edp
20:01 danvet: panels are garbage
20:01 Lyude: somehow edp doesn't surprise me there, but about regular DP?
20:01 danvet: I think collabora is still using it on some things
20:01 danvet: Lyude, I thought it's the same, the dp crc thing is tied to edp self refresh
20:01 danvet: but maybe there's another one
20:01 Lyude: nah you're probably correct :p
20:02 Lyude: i've never even tried the dp crc stuff myself
20:02 danvet: imirkin_, we have a macro for all crc checks, plus the interactive test stuff
20:02 danvet: "human please check" wouldn't be that much work
20:02 danvet: we already have that actually, minus making sure the crc tests don't fail
20:03 danvet: problem is more that you'd need fake crc to appease the test
20:03 imirkin_: but still the thing i'm looking for is "let's check if xyz works", not "does _everything_ work"
20:03 danvet: that part is a bit a mess with igt
20:03 danvet: it's kinda like a khr test suite in that regard
20:03 danvet: (worse, since kms doesn't have a spec to cross reference)
20:04 imirkin_: ;)
20:04 imirkin_: anyways -- i'm highly supportive of anything that enables me to write fewer tests when doing feature bringup on nouveau (esp when i'm not first)
20:04 Lyude: imirkin_: I mean you can always run only specific tests or run them by hand
20:04 imirkin_: all that said, i do feel like modetest is very useful to me
20:05 danvet: imirkin_, we could move it to igt/tools/ and port it to igt libraries
20:05 Lyude: that's what I was about to suggest :)
20:05 danvet: that would at least be some benefit in sharing the igt_fb.c scaffolding
20:05 danvet: but also > 0 amount of effort ofc
20:05 imirkin_: sure
20:05 Lyude: ajax has complained about these issues as well iirc
20:06 Lyude: it kind of sucks how much work it is just to ask the kernel to setup an fb in a specific way to make sure it works
20:06 Lyude: outside of the context of igt tests
20:06 danvet: the thing is I could ask intel do to this, but I think there's already too much an "intel forces igt on everyone" story going on
20:06 imirkin_: i may look at what it entails, esp when i get around to the next round of stuff
20:06 danvet: so don't want to go around actively killing existing things
20:06 imirkin_: (which will be more HDR-focused)
20:06 Lyude: igt, force o_O
20:06 Lyude: the weird rumors that come up in foss communities, I swear...
20:07 danvet: well like 90% of the "should we make igt mandatory for new uapi" discussion seemed to be about that
20:07 danvet: if I now go in and port all the existing things I won't be able to shake the evil overlord hat for years
20:07 danvet: :-)
20:08 imirkin_: well, there's also a reality that the majority of contributors to that are from intel, so if you want to play in that area, you can end up getting dragged along to things you didn't want
20:09 imirkin_: this reality (along with not being on the same wavelength with people) is a big reason of why i've taken a step back
20:10 imirkin_: which is also something i consider before contributing to a new project
20:11 Lyude: makes sense
20:11 imirkin_: having your own thing is more effort but less heartache
20:15 airlied: imirkin_: more heartache in some cases
20:15 airlied: like when someone writes a eeplacment and never notices your work
20:16 imirkin_: then i get to complain about kernel api breakage =]
20:17 airlied: like if you fork modetest, its likely people will just ovrrlook the fork
20:17 imirkin_: highly.
20:17 airlied: and keep reproducing your work in more broken ways
20:18 imirkin_: few people know about modetest in the first place.
20:18 airlied: and then you get pissed at them anyways even though it was your original intent
20:18 imirkin_: me getting pissed seems unavoidable :)
20:18 airlied: yup so a private fork is going to be ignored even more
20:19 airlied: just trying to avoid you feeling pissed in the future :-p
20:19 imirkin_: fool's errand. but i appreciate the effort :)
20:21 Lyude: btw imirkin_, my workload is (finally) starting to calm down, so I can take the time to look over these today
20:22 danvet: inertia is high, amd folks recently spent quite some time writing igt tests for syncobj
20:22 danvet: plus the usual amdgpu tests in libdrm
20:23 danvet: then didn't notice when they failed the (more throughrough) igt tests ...
20:23 imirkin_: Lyude: thanks!
20:23 Lyude: no thank you
20:23 Lyude: this is an area we've needed work in for a while in regards to nouveau
20:23 imirkin_: oh, this reminds me -- i'm on an intel chip now - i can test the gamma stuff properly.
20:24 imirkin_: (as opposed to squinting at the code and saying "yeah, that looks like it could work")
20:39 imirkin_: working as expected. nice.
21:02 Lyude: imirkin_: eek, somehow I missed the implication that the patch you sent was for libdrm and assumed you had just been thinking of moving this to libdrm
21:02 Lyude: that's what I get for multitasking too much
21:03 imirkin_: Lyude: yeah, modetest is in libdrm/tests
21:03 Lyude: would you be up to possibly seeing what work would be needed to get modetest ported over to the igt kms libraries?
21:03 Lyude: like we discussed earlier
21:04 imirkin_: i'll have a look.
21:06 Lyude: imirkin_: keep me updated :)
21:15 imirkin_: well, i doubt i'll look very soon
22:05 Lyude: rhyskidd: didn't get time to try your patches today but I'll do it first thing tommorrow
23:10 rhyskidd: Lyude: no problem