02:18imirkin: karolherbst: the tgsi TXF always has a lod
02:18imirkin: looks like you worked it out...
02:18karolherbst: imirkin: yeah, I've seen
02:19karolherbst: I guess for a txf I could actually just set levelzero in the input IR? allthough maybe I shoudln't do it, but it sounds like something we want to accept
02:20imirkin: i THINK that should be fine?
02:20karolherbst: it seems to work
02:20karolherbst: I had more fails, but those seems to be related to ARB shaders
02:20imirkin: check whether it works ok in the presence of offsets
02:20karolherbst: that's why I was wondering
02:20imirkin: i.e. texelFetchOffset
02:20karolherbst: do you know if we test that in piglit?
02:21karolherbst: or if the cts tests that?
02:21imirkin: pretty sure.
02:21imirkin: definitely some deqp's
02:22imirkin: unfortunately that has a dynamic lod =/
02:22imirkin: i dunno that we test texelFetchOffset(lod=0) specifically
16:45pmoreau: karolherbst: Do I get your Rb on the modified version of “clover: Avoid warnings from new OpenCL headers”?
16:58pmoreau: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/191/diffs?commit_id=39235fb5fe3c8061331f19ab9a4bf712985dde33
17:02karolherbst: pmoreau: yeah, looks good
17:02pmoreau: Thanks! I’m rebasing on the latest master, adding the extra two Rb and pushing the new version. Could you please merge it afterwards?
17:04karolherbst: yeah, I can
17:16pmoreau: karolherbst: Should be good to go. Had to rebase again as someone pushed in the mean time.
17:35karolherbst: pmoreau: queued the merge
17:36pmoreau: Thanks! How does that queuing work?
17:37pmoreau: Ah, I see. Good thing
18:39karolherbst: pmoreau: "Fast-forward merge is not possible. Rebase the source branch onto master to allow this merge request to be merged." :D
18:39pmoreau: Duh, what’s the point of the queue thing then --"
18:40pmoreau: Rebased and pushed
18:40karolherbst: let's try again :D
18:40karolherbst: was there actually a conflict?
18:42karolherbst: ohh wait, I am not allowed to rebase your branch :D
18:42karolherbst: was wondering why I couldn't rebase through the UI
18:43airlied: pmoreau: needs to tick the cbeckbox
18:43karolherbst: pmoreau: anyway, still a few piglit regressions left. Was able to fix most of them by fixing ptn :p
18:44pmoreau: airlied: Which checkbox? Don’t see one on the MR page.
18:44karolherbst: if it fails again, I just merge it locally :/
18:45prmiad: Hello, this may be a long shot, but im trying to install any linux distro on my computer but the geforce 6510se is making it impossible. I get an "Input Signal out of range" error
18:47prmiad: Ive tried to disable the nouveau module, ive tried to change the video resolution and refresh rate, ive tried different distros, nothing works. I wonder if any of you have ever had a similar problem and uncovered a solution?
18:48karolherbst: prmiad: try to boot with nouveau.modeset=0 and see if that changes anything
18:48karolherbst: prmiad: also, make sure you don't do any uefi boot
18:49prmiad: Ive tried to boot with the modeset set to 0, aswell as with the module beling blacklisted, but the same error occurs
18:49imirkin_: prmiad: using the DVI port?
18:49imirkin_: won't work
18:49prmiad: Oh no, the VGA
18:50imirkin_: ah. VGA should be fine.
18:50prmiad: Im sorry, i got it mixed up
18:50pmoreau: karolherbst: Had to rebase again
18:50imirkin_: DVI uses an external encoder
18:50karolherbst: pmoreau: :D
18:50imirkin_: and we never managed to figure out how to operate it
18:50imirkin_: (6150SE-special ... it's one of the IGP's iirc)
18:50prmiad: Yeah, integrated on the mobo
18:50karolherbst: pmoreau: I just merge it now...
18:51karolherbst: allthough, I wait for the build tests
18:51pmoreau: The one from 14 minutes ago passed
18:51imirkin_: prmiad: this is the issue i was thinking of - https://bugs.freedesktop.org/show_bug.cgi?id=26797
18:52prmiad: Yeah, as it stands my computer only has a vga port
18:52imirkin_: oh, you don't even have the DVI port? i guess it was only on some mobos then.
18:53prmiad: Yeah, its an HP slimline
18:53imirkin_: can you get a dmesg to see what's up?
18:53imirkin_: could be something similarly insidious
18:53prmiad: Its a liveCD, I havent been able to install linux
18:54imirkin_: and can't ssh in easily i suppose =/
18:54prmiad: And i cant get past the grub boot screen
18:54imirkin_: boot with nomodeset
18:54imirkin_: in the kernel cmdline
18:54prmiad: Ive tried
18:55prmiad: My kernel params have been a combination of "nomodeset nouveau.modeset=0 modprobe.blacklist=nouveau video=640x480@40"
18:56karolherbst: maybe remove the video one?
18:56imirkin_: yeah, that's the one most likely to screw things up :)
18:56imirkin_: just do "nomodeset"
18:56imirkin_: and nothing else
18:57prmiad: Ok ill try
18:57karolherbst: is there any good reason for the video one to still exist?
18:58prmiad: I figured the issue was the refresh rate and resolution of the monitor not being able to support the computer because the drivers are not installed
18:59prmiad: The error goes "Input Signal Out of Range; H=31.2kHz V=70Hz; Please change settings to 1620x1200 - 60Hz"
18:59karolherbst: without a driver you run into firmware land, and firmware is super broken
19:00imirkin_: hopefully 1920x1200?
19:00imirkin_: 1620x1200 would be quite weird.
19:00prmiad: Oh yeah, 1920, my mistake
19:00imirkin_: try nomodeset video=640x480@60 ?
19:01airlied: pmoreau: should be an mr option to allow others rebase and push branch
19:03pmoreau: airlied: Are you talking of this one “Allow commits from members who can merge to the target branch.”?
19:04prmiad: imirkin_: no the same error persists
19:04imirkin_: do you have a diff monitor?
19:04prmiad: None that support VGA
19:05imirkin_: although ... you see an image in grub?
19:05imirkin_: oh, i bet the vesa stuff is busted...
19:05imirkin_: try to disable vesa stuff
19:05imirkin_: i forget how one does that
19:05imirkin_: some distros insist on that bs
19:09prmiad: Im currently trying arch, which doesnt seem to have a way to disable vesa from the kernal params
19:09prmiad: Is their a distro that does?
19:12imirkin_: the gentoo install boot cd iirc doesn't enable it, or has an option to disable (i forget which)
19:12imirkin_: i'm sure there are kernel params to disable it tho
19:13imirkin_: prmiad: try adding vga=normal
19:15prmiad: No, the same problem persists
19:15imirkin_: you could ask in the respective distro channels
19:16imirkin_: sorry. i mostly came in to tell you about the DVI thing not working, since i figured karolherbst didn't know about that
19:16imirkin_: good luck
19:17karolherbst: hey :D
19:20prmiad: No problem, thanks for the helo imirkin_
19:21prmiad: And thanks for the help too karolherbst
19:22airlied: pmoreau: yes that one
19:23pmoreau: airlied: I see, thanks
19:24karolherbst: pmoreau: somebody pushed something again :D
19:32pmoreau: karolherbst: At this rate we will never get there. I thought you were going to do the merge locally but wait on the pipeline to finish. Do you want me to rebase against the branch?
19:32karolherbst: I will
19:32karolherbst: it's nearly done, so I'll merge soonish
19:32pmoreau: Btw, did you had the opportunity to run the piglit tests without Connor’s patch?
19:33pmoreau: If you haven’t, don’t worry, I’ll try to get it running locally.
19:33karolherbst: pmoreau: I ended up fixing regressions :D
19:34pmoreau: Dang, those people going in and fixing bugs :-D
19:34karolherbst: there are always subtle differences between tgsi and nir :/
19:34karolherbst: like tgsi always adds a lod for TXF
19:34karolherbst: nir... doesn't
19:35pmoreau: I see :-/
19:35karolherbst: like if we have a dynamically uniform lod of 0, we can flip a bit on the tex instruction and skip adding a source for it
19:37karolherbst: tex->tex.levelZero and if that value is false it expects another source :)
19:37karolherbst: worked before, no idea why
20:03karolherbst: pmoreau: pushed
20:04pmoreau: karolherbst: Thanks! \o/
20:16pmoreau: karolherbst: I rebased my two other branches on master.
20:47karolherbst: pmoreau: tests/spec/arb_gpu_shader_fp64/uniform_buffers/vs-array-copy.shader_test
20:47karolherbst: "shader_runner: ../src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp:1388: void nv50_ir::GCRA::checkInterference(const nv50_ir::GCRA::RIG_Node*, nv50_ir::Graph::EdgeIterator&): Assertion `vB->compound' failed."
20:51pmoreau: Thanks! I need to do some updates on my work laptop, because I haven’t been using it in a while, and it’s the only thing with Fermi+ card + working GUI that I have.
20:56karolherbst: pmoreau: which is the correct branch containing everything?
20:57karolherbst: okay, then I'll rebase my branch :)
20:58pmoreau: clover_support_nir_target will be the next MR, and contains OpenCL C -> SPIR-V + supporting NIR as an IR inside clover, and converting SPIR-V modules to NIR. The *_il_program adds the native SPIR-V support to clover, as an input IL.
21:01karolherbst: pmoreau: wasn't it like the other around once?
21:02pmoreau: It was indeed :-D
21:02karolherbst: I think I just pick your branch and be done with it
21:02pmoreau: But we don’t need the native support to get OpenCL C -> NIR working, and that is the main thing to get it. The native thing is just bonus and for the future. :-)
21:03karolherbst: meeting now, I'll guess I will rebase after midnight...
21:03pmoreau: Okay, ttyl
21:58pmoreau: karolherbst: Weird, that test passes even with the system library.
21:58karolherbst: pmoreau: on tesla?
21:59karolherbst: or fermi?
21:59pmoreau: On Kepler
21:59karolherbst: mhh, I've ran it on pascal
21:59karolherbst: pmoreau: are you using NV50_PROG_USE_NIR=1?
21:59pmoreau: Tried both with and without
22:00karolherbst: with the RA patch reverted?
22:00karolherbst: well, the TGSI path doesn't hit that issue
22:01pmoreau: With the RA patch reverted
22:01karolherbst: mhh :/
22:02karolherbst: there are also not soo many tests failing due to this, I guess we could postpone that patch for a little and I dig deeper into it testing it on other GPUs as well
22:02pmoreau: I might have done something wrong. I’ll investigate it more tomorrow, have to head out to a meeting.
22:06pmoreau: karolherbst: If we postpone that patch for now, I’ll go through all the other patches in the series and make sure to review as many of the remaining ones as possible. And then I’ll work on putting into shape the second MR, mostly that mega-opencl path from robclark .
22:07karolherbst: pmoreau: let me repush my branch then
22:23robclark: pmoreau, karolherbst, btw I think the conclusion from megadriver is we should split out a libnir instead.. I was semi-hoping that if I procrastinate enough we only have to do it for meson and not also for autotools
22:23robclark: although I suppose dropping autotools support for clover before dropping it for mesa/st is perhaps an option
22:25pmoreau: robclark: I’m not sure I’m following what you mean by “split out a libnir”.
22:26airlied:thinks the megadriver mightmake more sense :-)
22:27airlied: having a shared libnir.so that we have to drag around gets messy
22:27robclark: idea was instead of mega-cl, split nir into seperate .so that both clover and gallium drivers link against.. that also gets rid of two copied of nir (and glsl_types)
22:27airlied: maybe we can build CL + dri drivers into a mega-mesa
22:27karolherbst: robclark: I think we should rather have a libcompiler.so and put all driver compilers in there as well
22:27airlied: though linking against clang is probably worth avboiding
22:27robclark: yeah, mega-mesa might make more sense.. xexaxo1 and others had some arguments against mega-cl..
22:28robclark: I'd have to dig up that old thread from mailinglist to remember
22:28robclark: but I think theory was we could symbol version libnir or put mesa version in .so name or something like that to avoid issues w/ multiple different mesa versions..
22:28airlied:wonders how things would explode with GL and CL in one place
22:28pmoreau: I’ve been going through that old thread, but it’s taking a bit of time to settle in.
22:29pmoreau: One thing I was thinking of, is that we will want to be able to pass pointers from clover to GL and back, for the OpenGL-OpenCL sharing extensions.
22:30robclark: I don't think that should be a problem
22:30airlied: maybe we could dlopen libclang instead
22:30robclark: main issue is not crossing the glsl_type's streams
22:31pmoreau: That sounds like some ghostbusters issue now. :-)
22:31robclark: if both gl and cl have their own copy of nir/glsl_types and gallium driver, then there is no crossing of the streams
22:31robclark: heheh, reference is intentional :-P
22:33pmoreau: Right, you wouldn’t get any crossing, and libnir is most likely small enough that we don’t care having two copies loaded when doing gl + cl. But isn’t that going to be an issue if a glsl_type is passed from cl to gl, as the pointers might differ (which is the current issue IIRC)?
22:33robclark: presumably the type information doesn't cross the boundary??
22:34robclark: if it does, then yeah, it could be a problem
22:34robclark: anyways, mega-mesa might be worth looking into.. clover itself is small compared to mesa/st so that isn't going to really add any size
22:34airlied: robclark: yeah linking to clang is the bad bit
22:35airlied: and I'm not really sure how bad that is really
22:35robclark: well, we get that already on the gl side
22:35airlied: robclark: nope we link to llvm
22:35airlied: not fclang
22:35robclark: hopefully a bunch of pages that are never faulted in and no one really cares?
22:35pmoreau: I haven’t looked at how the extension work, but I would think that if you import an OpenGL buffer into OpenCL, you will retrieve some information about the buffer from the OpenGL driver, though it’s mostly going to be formats and sizes, not glsl_type.
22:49pmoreau: karolherbst: Wanna review a +212,506 −191,796 single commit? :-D https://github.com/KhronosGroup/OpenCL-CTS/pull/47/files Though I am not going to complain seeing all the extra patches being added to the public repo.