00:33 mareko: tarceri: no, but I think adding some number to GL_ACTIVE_UNIFORMS might be enough
00:52 mareko: tarceri: I'm busy with other stuff
01:53 imirkin: airlied: you could expose GL 4.6 without exposing the ext. i.e. put the no-op functionality in, and just don't show the string.
01:53 imirkin: (for aniso)
02:17 airlied: imirkin: nah cts tests fr it
02:18 airlied: would rather expose GL versions that aren't at least trying to pass CTS :-P
02:21 imirkin: airlied: what does it test for?
02:27 airlied: imirkin: not really sure, I think it counts the number of color transitions
02:28 Rush: imirkin: no expect by any means but exposing no-op extensions doesn't let software deal with the lack of extension ...
02:28 Rush: *I meant "no expert by any means"
02:29 imirkin: Rush: nothign for software to do
02:29 imirkin: it just improves image quality
02:30 Rush: imirkin: yes and I'm building digital painting software so quality is important :-P
02:32 imirkin: right, but if the driver doesn't do it, then it doesn't do it
02:32 imirkin: nothing software can do about it
02:32 imirkin: there's no "workaround"
02:32 imirkin: (other than to not use 3d accel at all)
02:33 imirkin: and what aniso does isn't even defined anywhere
02:35 airlied: yeah hence why implementing is messy, and I would assume a sw impl would be horrible performing
02:40 airlied: maybe gl4.6 will lure me in at some point, gotta get vulkan 1.0 done first
02:40 airlied: them lines won't draw themselves correctly
02:40 imirkin: :(
02:41 Rush: airlied: so I think the issue with "leaks" I had was a single long-running opengl context that was never explicitly destroyed. Will make sure to have short-lived contexts to have the texture memory cleaned up on a regular basis. Now valgrind only sees stuff such as "_mesa_symbol_table_add_symbol (symbol_table.c:197)" which I assume is some one-time allocation for the shader parser or smth like that
02:42 airlied: Rush: even a long lived context should kill textures memory
02:42 airlied: unless the app still has a handle to it
02:44 Rush: airlied: yeah .. the app is Node.JS ... and WebGL ("headless-gl") ... maybe it is an application / library issue and the explciit destroy simple forces things to wind down.
02:47 airlied: Rush: yeah killing the context will killall resources associated with it
02:48 airlied: yeah sounds like it might be a bug in those leves, around not deleteing texture resources
04:21 ccr: I assume post-suspend/resume cycle graphical weirdness is a kernel issue and should be reported there? (ancient NVidia GeForce Go chip + Nouveau in this case)
06:09 hanetzer: figure this may be a good place to ask, but is there any kind of public bugtracker for amd gpus? (not specifically in linux)
06:11 airlied: hanetzer: no non-linux noe
06:11 hanetzer: blep. well that sucks.
06:11 airlied: not sure I've seen any hw vendor ever have a public bugtracker
06:11 airlied: it would be pretty unmanageable
06:11 hanetzer: yeah. but then again, intel and amd are the only major gpu vendors playing ball with linux :)
06:12 hanetzer: so one would hope.
06:12 airlied: for linux you can file an issue in gitlab
06:12 hanetzer: yeah, already did for an issue that's relatively linux specific, but this is purely a hw issue :)
06:14 airlied: hanetzer: is that he overheating thing?
06:14 airlied: if you thought it used to work, just boot an older distro from a livecd
06:14 airlied: or install an older kernel
06:14 airlied: and see, if you can't find a old stable point, it's likely the hw is actually broken
06:15 hanetzer: no; pre-os (post/bios/boot menu/etc) I have no output over dp, so its purely hardware & firmware
06:15 airlied: did it used to work pre-os?
06:16 hanetzer: no, not with this gpu at least.
06:16 hanetzer: current gpu is asrock rx 5700 xt taichi, prior was a rx480 and rx580
06:38 ccr: hanetzer, perhaps a silly question, but have you checked that your CMOS battery is good?
06:39 hanetzer: its keeping settings (again, I'm able to do stuff over hdmi) and its fairly close to brand new
06:39 ccr: okay. just asked because I'm on Intel, but my ASUS uefi bios has a funny "feature" that if the CMOS battery is low/bad, it defaults to VGA output and does not initialize HDMI at all .. so only when OS initializes gfx, pictures appears on HDMI output.
06:40 hanetzer: I could replace it, just on the off chance
06:40 ccr: probably a long shot
06:41 airlied: hanetzer: the bios not working might be related though
06:41 airlied: if it works over hdmi
06:42 airlied: " It didn't happen until several weeks ago, " pretty much means try a kernel that used to work from a serveral weeks ago
06:42 airlied: or an old live iso
06:42 airlied: and see if it still works
06:43 hanetzer: no, "It didn't happen until I put in this gpu". Putting in the old one, works fine.
06:43 airlied: ah okay that isn't clear from the issue
06:43 ccr: ah.
06:44 hanetzer: could have sworn I said that. Sometimes I mix up whats in my mind and what I type/say :)
08:01 tjaalton: looking at mesa CI it seems that i965/iris/anv isn't tested at all?
08:13 glennk: hanetzer, what motherboard is it?
08:15 hanetzer: uh, Asus ROG CROSSHAIR VII HERO (WI-FI)
08:15 hanetzer: god I hate 'gaming motherboard' names
08:17 hanetzer: also modern phone names suck too. 'OnePlus 7t Pro 5g McLaren' wtf is all this.
08:18 hanetzer: glennk:^
08:19 glennk: heh, have the same one with a non-xt 5700
08:19 hanetzer: really?
08:19 hanetzer: what specific gpu do you have?
08:20 glennk: a gigabyte reference one, not sure what the model name is
08:20 hanetzer: would you mind dumping its vbios? :P
08:22 hanetzer: https://andrealmeid.com/post/2020-05-01-vbios2/ << if ya don't. Interested in picking it apart and seeing what happens. I assume dp-out works for you pre-os?
08:26 glennk: https://www.techpowerup.com/vgabios/215273/gigabyte-rx5700-8192-190616 should be equivalent to the one i have
08:26 glennk: what mb bios version do you have?
08:27 hanetzer: true, but its also possible those guys took some other technique. latest from asrock
08:27 hanetzer: erm. asus
08:27 hanetzer: ROG-CROSSHAIR-VII-HERO-WIFI-ASUS-3103.CAP << this file
08:28 glennk: i haven't tried that version, have something a bit older where pcie 4 is still enabled on it
08:28 hanetzer: hmm... that may have something to do with it...
08:28 hanetzer: what cpu is in it?
08:28 mceier: hanetzer: did you try changing dp standard in the monitor (if you can) to e.g. DP 1.1 ? I have 5700 XT and setting monitor to use DP 1.2↑ causes the same issue during boot (monitor doesn't turn on)
08:29 glennk: 3700x
08:29 hanetzer: mceier: not an option. have custom monitors, zisworks 4k monitors
08:29 mceier: ok
08:33 hanetzer: hmm. according to the bios 'changelog' it only disables gen4 on ryzen 3xxx
08:36 glennk: have you tried disabling fast boot and/or clearing cmos?
08:36 hanetzer: fastboot is off, cmos clear no change.
08:39 hanetzer: I'ma try a downgrade to before disabling of pcie4
08:43 glennk: if you have a pre-3xxx cpu pcie4 isn't a thing
08:46 withnomad: now let's talk about cuda and shader and constant root signatures , the last is the first real attempt. But cuda would duplicate the entries in the queues for array based copies of the same instructions. It can accelerate by default small snippets of straightline code. signatures are bit more interesting, as they can preload different instructions into queues and consume them even with using a single iteration (do not need multiple copies to be large)
08:46 withnomad: Now the implementation of it is unknown can be multiple versions, but they do not allow branches inside of such code. Which is what I am fixing up.
08:55 withnomad: it is fairly understood, that such behavior of the code comes when dispatcher is down and nops are forwarded to the circuit hence, and this really is seeming to be the case when RST signal after halting is captured and made hence unfunctional of flushing the internal queues.
09:00 withnomad: i think coherency domains are in core of vulkan allready, and inherent thing of SIMD archs. So texture cache can be invalidated to the instruction cache to make self-modifying code to work right! Second option is to use no page tables and write combined memory.
09:03 withnomad: the more complex version needing register allocation hacks requires round about 100words in i-cache to be reused and works without self-modifying code.
09:48 daniels: tjaalton: Intel's CI system is completely separate from the upstream one
09:49 tjaalton: right
10:25 AndrewR: airlied, hm, I compiled git mesa (git-636f770233) but can't see how LP_CL=1 works (clinfo still sees no platforms) . I tried to set MESA_LOADER_DRIVER_OVERRIDE=swrast GALLIUM_DRIVER=llvmpipe LP_CL=1 before clinfo - "No devices found in platform"
10:31 MrCooper: AndrewR: did you build Mesa with gallium-opencl & opencl-spirv enabled?
10:32 AndrewR: MrCooper, meson ../ --prefix=/usr/X11R7 --strip --buildtype debugoptimized -Degl=true -Ddri-drivers=r100,r200,i965,nouveau -Dplatforms=drm,x11 -Dgallium-drivers=i915,r600,radeonsi,swrast,virgl,nouveau,r300,iris -Dvulkan-drivers=amd,intel -Dgallium-nine=true -Dgallium-opencl=icd -Dgallium-va=true -Dgallium-xvmc=true -Dgallium-xa=false -Dopencl-spirv=true - I think yes ?
10:34 withnomad: Actually ancient times there was right away such feature as display lists. This enforced the coherency protocol right away. Compatibility profile needs to enable profiles down to ogl 1.0. I would choose the self-modifying code and hence the codepath which packs the instruction stream too.
11:03 airlied: AndrewR: probably missing the libclc spirv library
11:04 airlied: since you have to build libclc from git
11:06 AndrewR: airlied, yeah ...still have old libclc (will try to rebuild it ...but may be not right now). Thanks!
11:44 karolherbst: airlied: we will get the required one with llvm-12, no?
11:57 AndrewR: airlied, strange SPIRV-LLVM-Translator-llvm_release_100 (for llvm 10) does not install llvm-spirv ..manually copied it to /usr/bin, now libclc found it and trying to build itself ...
12:19 AndrewR: airlied, it works: Device Name llvmpipe (LLVM 10.0.0, 256 bits) \o/
12:31 AndrewR: airlied, luxcoreui (2.4alpha from may 2020) seems to work, too :}
12:52 Akien: Hi there. Is there a dedicated channel to talk about zink, or would it be here?
12:59 withnomad: Last time i looked at zink (though i do not know too much about vulkan) it lacked so many features, that it was not very appealing. As getting vulkan enabled cpu rasterizer you might be better off with gfx-rs and the gfx-compability layer and run it off ontop of llvmpipe maybe.
13:00 karolherbst: withnomad: what you say makes no sense
13:01 withnomad: karolherbst: no sense can be made for a guy who can not think.
13:01 karolherbst: ...
13:01 withnomad: gfx-rs has ICD compability and opengl backend which could probably run ontop of llvmpipe
13:02 karolherbst: besides the point, and please stop insulting people
13:08 withnomad: https://www.d.umn.edu/~gshute/logic/alu.xhtml all the gates in ieee1164 make use of multiplexers, which reset the state of alus even on bubbles, if one wants to get closer look into how multiplexers work, there is a patent. https://patents.google.com/patent/US6675182
13:13 withnomad: if you would not rotate the stuff in mux and wraparound accordingly, it would damage the logic of course, cause it would according kichhoff law would drive possibly too big currents to the logic.
13:15 daniels: Akien: yep, #zink is it :)
13:15 kisak: hello withnomad, looking at the backscroll and stepping back for a moment, what are you trying to achieve at the moment? It appears you're expressing ideas for the sake of doing so, but there's no context or issue you're trying work out in doing so.
13:16 withnomad: you might be thinking that perhaps i was wrong, since there is a parallel mux, but parallel case mux does not mean it is parallel.
13:16 withnomad: begin is parallel context, but if you embed different cases in different begin blocks it won't be a mux anymore
13:16 withnomad: all the items of case inside the begin are executed sequentially still.
13:17 withnomad: hence every bubble in the circuit will take as much energy as real work.
13:18 withnomad: it is analogoous to mechanical parts even like breaking inside the electrical car, to use breaks in the car, it requires energy, and this can be directed to the capacitors like supercapacitors developed for that purpose.
13:18 karolherbst: kisak: that person is well known, I just wasn't aware who it was...
13:27 linkmauve: Hi Intel people, what could be the cause of this kind of artifact on a gen7? https://pix.mathieui.net/o/yCDqS.jpg
13:27 withnomad: this is fairly long time ago, when the solution was offered, the easy version is quite simple, some lines in the driver and some things preloaded to cache and it will fill the bubbles subsitutions like doing real work instead of blocking.
13:28 linkmauve: The horizontal lines blink, and the “orientation” changes based on resolution.
13:29 withnomad: because display lists are in fact cached, from times of ogl1.0 that requires cache coherent protocol to be implemented always, and a route from one cache to another, which on gpus is clockless due to texture arbiters.
13:30 withnomad: so bu torning down the dispatcher , this is the first step , colliding the caches and invalidating the content is the other step, and you should have all the perf in the world.
13:30 linkmauve: This isn’t my computer, nor am I close to it so debugging is a bit harder, it also didn’t happen on Ubuntu 16.04 to 19.10, and only started now on ArchLinux (Linux 5.8).
13:31 withnomad: i also developed new intrinsics for long latency ops and so this gets into more wins, and also all compression, but i won't commit that work.
13:31 mripard: danvet_: have you seen https://lore.kernel.org/dri-devel/1bdbebd704d01ccf57eb2428e1cbe33e64c94b95.1600961400.git-series.maxime@cerno.tech/ ?
13:32 mripard: I guess you'll have some comments :)
13:32 linkmauve: Sorry not ArchLinux, Debian Sid (so probably same kernel).
13:33 mripard: (like do we want to have it on atomic_begin _check and _flush too?)
13:34 danvet_: mripard, oh where's that magic cocci script?
13:34 danvet_: for one offs like this would be good to include it in the commit message
13:35 danvet_: mripard, aside from that I like
13:35 danvet_: well the only bikeshed I have is that I'm not sure drm_atomic_state should be a state
13:35 danvet_: it's more like the commit
13:35 danvet_: but that ship sailed unfortunately :-/
13:35 danvet_: or it would at least be a much larger scale renaming exercise
13:37 mripard: danvet_: https://pastebin.com/h0AgxWbq
13:37 mripard: it's pretty long, but I'll include it in the commit log if you want
13:38 danvet_: yeah I think that's useful
13:38 danvet_: since we have more hooks that need the same transformation, eventually
13:39 bnieuwenhuizen: danvet_: I have been thinking a bit more about getfb2, but isn't changing the number of planes (from 1 without modifiers to 2 with modifiers) returned from getfb2 considered a forbidden change because non-modifier-aware mesa can't handle multi-plane images?
13:39 withnomad: i was not interested in vulkan right when the project was started as MANTLE, because this started with totally wrong ideas gloals or missions. there is no point to feed dedicated gpu memory from cpu side of the bus in the ring.
13:39 withnomad: and vulkan offers maybe some clean ups, which would be ok but...
13:39 withnomad: the ideas are totally wrong.
13:39 danvet_: mripard, the other bikeshed: maybe we should add a boilerplate to all the hooks that now have the drm_atomic_state *state argument
13:39 danvet_: about what this is good for (aka everything)
13:39 danvet_: instead of just removing the existing blabla
13:39 danvet_: but I guess also ok as-is
13:40 danvet_: mripard, anyway, with the cocci added for reference: a-b: me
13:40 mripard: awesome, thanks :)
13:44 withnomad: and for reclocking , since there are no clocked logic blocks , since there can not be more than one which is in the dispatcher, otherwise elementary games would not run even simple games would not process well. so the reclocking is a frequency generator with main purpose to fuck up someones eardrums when some uses this as a wheapong or make new kettle for heating water for the tea.
13:49 withnomad: to torn a dispatcher a simple halt can be used , several other options, and in opencl that requires redefining one function in the public header.
13:49 withnomad: this function sends rst signal to the chip, and it allows to redefine and revere it and call the redefined one instead,
14:35 Akien: daniels: thanks!
14:49 MrCooper: someone who knows python should go through the "git grep 'env python$'" results and change them to say python3 or python2 instead
14:55 jekstrand: dcbaker: ^^
14:56 dcbaker[m]: Which project are we talking about?
15:03 jenatali: jekstrand: Was there something you were waiting for my review on?
15:04 jekstrand: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6750 is going to affect you but karolherbst reviewed it and I don't think CF is really your area.
15:04 jekstrand: jenatali: You also expressed interest in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6871
15:05 jenatali: jekstrand: I'll take a peek but yeah CF's not really my area
15:05 jenatali: Ah yeah, I'll check that one out too :) thanks!
15:05 jekstrand: yw
15:06 karolherbst:had to deal with too many random things the past days/weeks :/
15:06 pcercuei: I can trigger a bug in Linux' MM code by running "fuser -k -HUP /dev/dri/card1"
15:06 pcercuei: one out of ~10 times, I get this: https://pastebin.com/raw/PXFp7k7a
15:07 jekstrand: jenatali: There was a bug in the CF structurizer that I came across when we first landed it but I didn't understand the code very well and applied something of a band-aid fix. That MR has a what I believe to be a correct fix.
15:07 pcercuei: I don't really know what BUG() it is, I don't see any in get_user_pages_fast_only()
15:07 jekstrand: jenatali: Also, after spending about a solid week with the structurizer I think I genuinely understand the over-all structure and am reasonably convinced that it's probably correct for the vast majority of cases.
15:08 jekstrand: I'm not 100% sure about irreducible cases but those are unlikely to come up in practice when we pass -O0 to clang.
15:10 MrCooper: dcbaker: mesa
15:11 jenatali: jekstrand: Awesome, sounds great. One more reason we need to get our code on top of master
15:12 jekstrand: Yeah...
15:25 pinchartl: does anyone know what NV stands for in semi-planar formats ? is it a historical reference to nvidia, or something else ?
15:29 ajax: that's... a really good question.
15:39 danvet_: linusw, is your plan to invest a bit of time into fbdev emulation for android with your linaro hat on?
15:40 linusw: danvet_: yeah makes sense.
15:40 vsyrjala: pinchartl: i always thought the V just comes from YV12. why the N though? native?
15:40 danvet_: if you do, I think it would be great to extend the fbdev testcase in igt with that stuff
15:40 danvet_: so we have higher chances of things not breaking again
15:40 linusw: danvet_: I'm syncing som gigs of Android ftm
15:41 danvet_: lol :-/
15:41 danvet_: e.g. we have vblank wait support for fbdev, so a testcase that checks the drm driver for vblank support
15:41 danvet_: and then makes sure the fbdev one works too
15:42 danvet_: or if we really have to add pixel format change support, some test that tries to exercise that
15:42 danvet_: it can cheat after all and look at the kms side for what should be supported
15:42 linusw: danvet_: once I understand the problem that should be doable ... I guess. I don't know what igt is or anything.
15:42 jenatali: vsyrjala: I wonder if N is for iNterleaved
15:43 danvet_: linusw, https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation
15:43 danvet_: this igt
15:43 danvet_: there's an fbdev testcase, but it's not very smart yet
15:44 danvet_: I guess for better integration it should try to open the fbdev device for the drm driver we're trying to test
15:44 danvet_: at least as a default
15:52 vsyrjala: jenatali: yeah, could be
15:55 linusw: danvet_: is this something we plan to fold into the kernel self-tests?
15:56 danvet_: linusw, thus far not
15:56 danvet_: but it's serving a somewhat similar purpose
15:56 danvet_: just for drm
15:57 danvet_: other stuff like e.g. xfstest is also out of tree
15:57 danvet_: the things we have in selftests are our in-tree unit tests
15:57 danvet_: which I'm hoping will become kunit tests eventually, maybe, in some future
15:57 danvet_:has too many dreams perhaps
16:01 AndrewR: karolherbst, interesting, I tried to apply https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4974 and build fails with "/usr/bin/../lib/gcc/i586-slackware-linux/5.5.0/../../../../include/c++/5.5.0/ext/new_allocator.h:120:23: error: no matching constructor for initialization of 'clover::module::symbol'"
16:03 AndrewR: https://pastebin.com/K69bpRCJ
16:05 karolherbst: ehh.. ehh?
16:06 karolherbst: ahh
16:06 karolherbst: maybe some conflict
16:06 karolherbst: will take a look later
16:43 jekstrand: jenatali: Did you want to give any opinions on the structurizer MR? If not, I'd like to assign Marge.
16:44 jenatali: jekstrand: I don't think so, I'd say go for it
16:44 jekstrand: cool
16:50 jekstrand: cmarcelo: Could I get you to look at the first patch in !6871. The nir/find_array_copies one?
16:50 jekstrand: Or maybe cwabbott
16:50 cmarcelo: jekstrand: will take a look
16:50 jekstrand: cmarcelo: You would likely be interested in that whole MR
16:55 jekstrand: jenatali: Should we be expecting a MR against master soon? :-)
16:55 jekstrand: A very large MR
16:56 jekstrand: karolherbst: We really need to think about adding an optimizer to clover. I can write up a basic opt loop if you'd like.
16:57 jekstrand: karolherbst: Writing all these CL-based optimizations without having a good way to CI them is making me nervous.
16:57 karolherbst: yeah
16:57 karolherbst: makes sense
16:57 karolherbst: I also wouldn't mind if we share the basic stuff with st/mesa
16:57 karolherbst: so drivers can more or less expect the same stuff
16:58 jenatali: jekstrand: We're pushing through some issues trying to get conformance submissions put together for CL and GL, once those are submitted we'll hopefully have some more cycles to continue rebasing on top of master
16:58 jekstrand: I guess you did add a gallium_nir thing, didn't you?
16:58 karolherbst: uhm... I don't think so?
16:58 karolherbst: but there is a callback drivers can implement so that gallium calls into driver specific opt loops
16:58 karolherbst: we could mandate that for clover
16:59 jenatali: jekstrand: I also wouldn't say "very large", only moderately large :)
16:59 jekstrand: jenatali: I guess you are mostly adding files so, unless you're trying to keep history, it doesn't have to be a lot of patches.
17:00 jenatali: jekstrand: Yeah, I think we're going to throw away history for the bits that go upstream probably, but kusma's been doing most of the work trying to stage that
17:00 jenatali: And all of the bits that touch upstream should already be there, except for conversions and printf
17:01 jekstrand: Right
17:01 jekstrand: Conversions......
17:01 jekstrand: I've still got a hack for that in my branch
17:01 jenatali: Yeah...
17:01 jekstrand: My kernels want round-up/down float->int
17:01 jenatali: And on top of conversions, the vload_half/vstore_half
17:02 jenatali: I don't remember if we decided how we wanted to handle fp16<->fp32 conversions, since there's already opcodes with rounding modes
17:02 jekstrand: I think the conversion intrinsic should handle everything. The lowering pass can then turn them into the opcodes we have.
17:02 jenatali: But the CL functions require adding the round-up and round-down variants as well
17:02 karolherbst: mhhh
17:03 karolherbst: did we actually decide on how we want to handle conversions in nir longterm?
17:03 jekstrand: Honestly, I think the intrinsics may be a good way to do it
17:03 jenatali: karolherbst: I think we agreed that a conversion intrinsic + constant indices for mode, plus a lowering pass
17:03 karolherbst: ahh, yeah
17:03 karolherbst: that sounds sane
17:04 karolherbst: sounds like a lot of code needs reworking but I guess...
17:04 karolherbst: maybe it helps to know what hw actually supports?
17:04 karolherbst: uhm.. supports what
17:04 jekstrand: If we really care about optimizing them or constant-folding, we can break the few common ones out into ALU ops.
17:04 karolherbst: I could probably come up with a list of conversions nv hw supports directly
17:04 jenatali: I thought we said that we'll just always lower the intrinsics when the source is a constant so we can fold it?
17:04 jekstrand: I expect the lowering pass will take a callback for "can you handle this one?"
17:04 jekstrand: jenatali: Oh, right. Yeah, that works.
17:05 karolherbst: mhhh, how do we add the rounding mode in there then?
17:05 jenatali: karolherbst: As a constant index?
17:05 karolherbst: sure, but for the constant folding
17:06 karolherbst: if we convert it to alu ops, then we would need all types anyway
17:06 jenatali: We'll lower it into a series of alu ops to do the rounding
17:06 karolherbst: ohhh
17:06 jenatali: Then all of those will fold away
17:06 karolherbst: mhhh
17:06 karolherbst: I guess
17:06 karolherbst: and then drivers can opt in for: _always_ give me the convert intrinsic instead of the alu ops
17:06 jenatali: That way we don't have to implement it in both nir_builder and C, and we don't have to explode our opcodes
17:07 jenatali: We've already got nir_builder implementations of rounding, it's just baked into vtn right now, so it'll just be a matter of refactoring that into a lowering pass
17:07 karolherbst: I am just wondering if we have enough conversion opts that it's worth caring about it?
17:08 karolherbst: like would we even need to keep the alu ops at all
17:08 karolherbst: or could one opt pass on the intrinsic handle everything already
17:08 karolherbst: heh.. we have u2fmp now as well.. mhh
17:08 jekstrand: jenatali: I'd be up for writing the code to add the intrinsic, pull stuff out, and make the pass. I just don't have a good way to test it thoroughly.
17:09 jenatali: jekstrand: CL CTS test_conversions ?
17:09 karolherbst: doesn't test constant folding
17:09 jekstrand: jenatali: Yea, I guess.
17:09 jenatali: Oh sure
17:09 jekstrand: karolherbst: I'm not worried about constant folding if the solution is to lower to ALU first
17:09 jenatali: jekstrand: test_conversions is *very* thorough
17:09 karolherbst: jekstrand: I am wondering if we even need the alu ops
17:09 karolherbst: we could just.. get rid of them entirely
17:10 jekstrand: karolherbst: Which ALU ops are you suggesting we get rid of?
17:10 karolherbst: conversion ones
17:10 jekstrand: jenatali: Is it all currently living in your branch? If so, which branch?
17:10 jekstrand: karolherbst: I think we want to keep the basics.
17:10 jekstrand: karolherbst: We want nir_opt_algebraic to be able to work on them
17:11 jekstrand: And extending that to work on intrinsics is probably possible but a massive pile of design work
17:11 karolherbst: why though? I doubt it would be a lot of work to port the opts over to work on the convert intrinsic
17:11 karolherbst: right
17:11 karolherbst: it's a lot of work
17:11 jenatali: jekstrand: Yeah, you can find it in https://gitlab.freedesktop.org/kusma/mesa/-/blob/msclc-d3d12/src/compiler/spirv/vtn_alu.c#L695
17:11 karolherbst: not arguing that
17:12 jenatali: jekstrand: It's split across a series of MRs of original implementation, bugfixes, adding new fp16 opcodes, etc, but I can track them all down if you'd rather go based on commits rather than tip-of-tree code
17:12 jekstrand: jenatali: tip-of-tree is fine. My intention is to pull the stuff out into a builder helper and then work on top of master from there.
17:13 karolherbst: AndrewR: compiles fine here
17:13 jenatali: jekstrand: Cool, sounds great. Let me know if you need help
17:14 karolherbst: ohh.. maybe it's a 32 bit thing?
17:22 jekstrand: jenatali: Any reason why it's using both a destination type and a destination bit size rather than a sized type?
17:23 jenatali: jekstrand: Probably not a good one
17:23 jekstrand: Also, why is it looping over channels rather than using vector ops?
17:24 jenatali: jekstrand: https://gitlab.freedesktop.org/kusma/mesa/-/issues/43
17:25 jenatali: Please feel free to improve the code as you see fit :)
17:30 jekstrand: Oh, this is daniels code. :)
17:30 jenatali: Yeah, most of it
17:31 jenatali: I added int -> float rounding, and a couple tweaks/bugfixes
17:32 daniels: the NIR documentation wasn't very helpful :P
17:33 jekstrand: daniels: If you can tell me where the documentation is, I can fix it. :P
17:38 Kayden: hahahaha
17:41 jekstrand: A long time ago, I wrote something of a blog post about NIR providing some high-level design information. I should do that again only put it in the mesa tree and make it up-to-date.
17:41 anholt: jekstrand: being able to put docs on docs.mesa3d.org now is pretty cool
17:41 jekstrand: anholt: Yeah...
17:42 anholt: .rst does not delight me, but anything is better than handwritten html I never wanted to touch or awful wikis.
17:42 jenatali: jekstrand: Yeah that blog post was my only primer for NIR before diving into it, and it really isn't sufficient :(
17:43 jekstrand: anholt: Yeah, rst isn't amazing. I tend to prefer markdown. But it's not bad and sphinx is pretty well made, IMO.
17:44 karolherbst: sphinx can accept markdown files though, but I assume it doesn't give you all the features of rst then :p
17:51 karolherbst: AndrewR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4974/diffs?commit_id=45c7dba65de658fa5217e1f132e9218ba22a76c6#7604d7c288c0a605c9143852901c247db21d5f92_112_131
17:59 lrusak: is triple buffer simple swapping in a queue of buffers rather than just swapping back and forth between two buffers?
18:01 lrusak: commit in question -> https://github.com/lrusak/xbmc/commit/e38e97a20940a9c898f99dc293ce8a11a48f2aea
18:01 bnieuwenhuizen: lrusak: it is not a queue. frames can be skipped for display if rendering is faster than the monitor
18:09 bl4ckb0ne: does the panfrost driver has vulkan support for mali t860?
18:10 bnieuwenhuizen: bl4ckb0ne: no
18:10 bnieuwenhuizen: no vulkan support yet for panfrost
18:10 cwabbott: jekstrand: don't forget about https://people.freedesktop.org/~cwabbott0/nir-docs/
18:10 bl4ckb0ne: bnieuwenhuizen: thanks!
18:10 cwabbott: definitely horribly out-of-date by now though
18:11 jekstrand: cwabbott: I think I have a slightly more up-to-date version of that in my tree somewhere
18:12 jekstrand: jenatali: Some of these helpers confuse me. I'm not 100% sure they're correct....
18:12 jenatali: jekstrand: They do pass the CTS - what's your concerns?
18:13 jekstrand: jenatali: It could be cases that never come up
18:13 jenatali: jekstrand: Possible, since we don't support double or half
18:13 jekstrand: jenatali: But, for instance, it does a nir_imm_floatN_t(b, FLT_MAX, src->bit_size). What is that going to do if FLT_MAX can't fit?
18:13 jenatali: Everything else should come up though
18:14 jekstrand: In any case, we can handle this all in review.
18:14 jenatali: Hm... I think CL doesn't generate those conversion ops for halves
18:14 jekstrand: I'm going to post it more-or-less as-is
18:14 jenatali: Sounds good
18:14 jekstrand: With a few cosmetic modifications
18:15 jenatali: jekstrand: CL doesn't generate the conversion opcode when rounding modes are used for fp16, it can only explicitly specify rounding modes when using the vload/vstore_half extension opcodes
18:22 daniels: jekstrand: the documentation is in MR comments and #dri-devel backlog afaik
18:23 daniels: but yeah, more seriously, if the question is 'why this way?', the answer is 'because I'd not realised there was another way'
18:32 lrusak: bnieuwenhuizen, ah okay, so triple buffering will only help with async?
18:42 ajax: enh. it helps in pretty much any situation where you render faster than the display and you don't mind using 100% of the cpu/gpu time.
18:42 ajax: synced presentation or not
18:43 bnieuwenhuizen: In theory what ajax said, in practice it has some issues that prevent it from really helping with latency
19:03 AndrewR: karolherbst, thanks, I tried to manually edit diff I downloaded, but currently mesa rebuild in progress - it will take some time ..Thanks a lot for such superfast response!
19:08 jekstrand: jenatali: Can you vstore float16?
19:08 jenatali: jekstrand: Yep
19:08 jekstrand: Oh, yes you can. I see what's happening now.
19:13 jekstrand: jenatali: I just pushed to a for/jenatali branch on my gitlab with the refactored conversion helper. I think things are a bit cleaner now. Time to cherry-pick it all onto my iris clover branch so I can do the lowering pass and have some hope of testing it.
19:14 jenatali: jekstrand: Sounds good :)
19:27 jekstrand: Ugh... Have to figure out how to rebase on anholt's loader changes
19:35 austriancoder: MrCooper: any thoughts about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6790 ?
19:46 jekstrand: karolherbst: What do I need to install to get libclc?
19:46 karolherbst: uhm.. ask jenatali or airlied for the binary :p
19:46 karolherbst: not sure if we have binary packages with the spirv bits out yet
19:46 jekstrand: Someone want to shuffle me a sketchy binary?
19:47 karolherbst: I could probably forward what I have today, but it might be out of date
19:47 airlied: there is one in the ci docker image :-p
19:47 karolherbst: ahh, fair enough
19:47 jekstrand: airlied: You landed your CI patches?
19:47 airlied: but i built one locally yesterday, gimme a few mins to get to a pc
19:48 airlied: jekstrand: still in mr,
19:48 airlied: piglit has inconsistency in how many tests run for some reason
19:49 jekstrand: weird
19:50 jekstrand: I could build it but that would require switching LLVM versions somewhere in my stack. 😬
19:51 airlied: https://people.freedesktop.org/~airlied/scratch/spirv64-mesa3d-.spv
19:51 airlied: jekstrand: not really
19:51 airlied: you can build it with llvm 10
19:51 jekstrand: why is there a trailing -?
19:51 airlied: libclc can be built out of tree
19:51 airlied: jekstrand: just triples
19:52 airlied: originally it was spirv64--.spv, not sure why mesa3d got added :-P
19:52 jekstrand: heh
19:52 airlied: libclc libraries are all triple named
19:52 jenatali: airlied: I think it was suggested from LLVM upstream folks
19:54 jekstrand: airlied: Got a pkgconfig to go with that?
19:54 airlied: jekstrand: just install distro libclc
19:54 airlied: and drop it in the dir
19:55 jekstrand: oh, ok.
19:57 jekstrand: Woo! I'm up-and-running again!
20:03 airlied:will hopefully track down piglit issue today, but have a kernel regression to work out in parallel
20:05 airlied: might be worth adding a few conversiony tests to piglit
20:05 airlied: at least hit some of the more useful cases
20:05 jenatali: As long as they run faster than the CTS...
20:06 jenatali: I never want to run that test ever again
20:06 anholt: how long is the cts taking? and are you running in parallel?
20:06 airlied: yeah the CTS is probably a bit too comprehsive
20:09 jenatali: anholt: That specific test has ~900 test groups, for each of (source type, dest type, rounding mode) running through every single possible input value
20:09 jenatali: It's... ridiculous
20:09 jekstrand: Oh, my....
20:10 AndrewR: karolherbst, 6040 also fails after i applied it on top of 4974 ... "../src/gallium/frontends/clover/core/printf.cpp:268:46: error: too few arguments to function call, expected 2, have 1"
20:11 airlied: jenatali: hours or days? :-P
20:11 jenatali: airlied: On hardware, like 28 hours?
20:11 jenatali: I tried on WARP (our D3D software GPU) and gave up after a few days
20:12 jenatali: After it only made it through like 50 test groups...
20:12 airlied: okay so on llvmpipe we could expect it to take a while :-p
20:12 jenatali: Yes, a while :)
20:13 jenatali: airlied: Math bruteforce is up there too, though not quite as long
20:17 jekstrand: airlied, jenatali: Sounds like we need a CPU rasterizer race!
20:17 airlied: jekstrand: we both just need to get threadrippers first :-p
20:17 jenatali: airlied: I think we actually have one on order specifically to accelerate running the CL CTS on our software driver......
20:18 airlied: seomday I'll get CL CTS built locally and try and run it :-P
20:19 airlied: can I run cl1.2 from master yet?
20:20 jenatali: airlied: Don't think so, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4974 is still open
20:20 jenatali: Though I'm not sure how much of that is AMD-specific vs NIR
20:21 airlied: jenatali: I meant with CTS as well :-P
20:21 airlied: it had some wierd cl 1.2 in a branch
20:21 jenatali: airlied: Oh, yeah, CL1.2 CTS is merged into master
20:21 jekstrand: CL 3.0 here we com!
20:21 jekstrand: *come
20:22 jenatali: I'm looking forward to flipping that switch :)
20:22 jekstrand: Supposidly, it's going to be very little work.
20:22 jenatali: Yeah, just implement some caps and functions
20:24 airlied: subgroups?
20:24 jenatali: Optional
20:24 jekstrand: Everything is optional!
20:24 airlied: ah cool
20:24 jenatali: Yeah, all you need to implement is the caps to say you don't support anything :P
20:24 jekstrand: Well, nearly everything. I think they made a few quality-of-life things required
20:24 jenatali: Right
20:25 airlied:fails to build CL CTS again
20:25 airlied:wonders what is so hard about just making mkdir build; cmake -G Ninja ..; ninja work
20:26 jenatali: airlied: What's failing for you? I didn't think it was that hard...
20:26 jenatali: airlied: Did you see https://github.com/KhronosGroup/OpenCL-CTS/blob/master/build_lnx.sh ?
20:26 airlied: yeah it's full of paths to things it surely can find itself
20:26 airlied: but can't
20:26 jenatali:is apparently too used to that from Windows development...
20:27 airlied: and README.md is very is insightful :P
20:36 yshui`: will glXSwapBuffers block glFinish in mesa? The impression I got from my experiments is that it doesn't.
20:39 anholt: no, glfinish shouldn't care about a previous swapbuffers.
20:39 anholt: (but also, if you're calling glfinish, you're almost always doing something wrong)
20:45 yshui`: i see. so the opengl wiki is wrong. also the nvidia driver does wait for swap buffers in glfinish.
20:46 yshui`: why is glfinish bad?
20:47 anholt: generally, you don't want to stall your gpu.
20:48 anholt: there's no reason to call glfinish, unless you're doing some external synchronization thing, but if you are you should be using fence fds to keep from stalling the gpu.
20:52 yshui`: yes, using fences would be idea. but if my application is light on gpu usage it shouldn't matter that much.
20:52 anholt: but, like, what are you doing where glfinish is something you need to call in the first place?
20:54 yshui`: minimize input to screen latency in a X compositor
20:55 yshui`: if i let the gl commands sit in the queue waiting for buffer to swap, the latency would be > 1 frame
20:56 yshui`: if i wait for swap to complete before starting render, the latency will be within 1 frame
20:58 anholt: if you want to wait for a swap, you should probably be using glXWaitForSbcOML() or whatever the egl equivalent is, not a glfinish.
20:59 yshui`: nvidia doesn't have that iirc :'(
20:59 anholt: (but if you're trying to do that, why specifically the swap as the time to start compositing, as opposed to, say, halfway through the frame time?)
21:02 yshui`: well it's a start. to start rendering midway through a frame i need to gauge how long the render will take.
21:03 yshui`: so i dont miss the vblank
21:07 yshui`: but ideally i do want to start rendering as late as possible
21:08 ajax: anholt: did i965/iris ever get a fence implementation that wasn't equivalent to glFinish though?
21:11 ajax: yshui`: "let gl commands sit in a buffer" - SwapBuffers implies glFlush, implies rendering is submitted to the hw before SwapBuffers returns. Finish is even more brutal, in that it waits for rendering to _complete_
21:12 yshui`: the hw cannot start processing those commands before the buffer is swapped
21:13 ajax: i mean... if the rendering destination is awaiting a previous swap to release, maybe?
21:13 yshui`: you cannot writing to the back buffer when it's still the front buffer
21:13 yshui`: yeah, that is why i need to wait for the buffer swap
21:16 ajax: but, if the buffer you're waiting to render to is _currently_ the front, then you've already got a swap pending. right? (assuming not triple-buffering)
21:17 yshui`: yes.
21:18 ajax: (this conversation is giving me deja vu)
21:20 yshui`: why?
21:21 AndrewR: karolherbst, https://pastebin.com/nfNEey3e (full compile error with printf patch applied)
21:21 yshui`: yes. the pending swap has to finish, before the comnands can be processed
21:22 ajax: right. so nvidia doesn't have glXWaitForSbcOML, but it does have glXWaitVideoSyncSGI, which is a bit more awkward as a "sleep until the frame posts" api but can be made to work
21:23 yshui`: i think i would just use glfinish on nvidia. it's improper, but nvidia's glfinish does wait for swap
21:24 ajax: (why - convo in #xorg-devel the other day about what glx extns nvidia supports)
21:24 ajax: yeah, fair enouhg
21:28 yshui`: huh, nvidia does have sgi video sync
21:29 karolherbst: AndrewR: well, if you merge multiple MRs together locally, you have to resolve your compile errors yourself :p I think the MR is just conflicting with the other one
21:29 ajax: i'm not really sure why they don't have OML_sync_control tbh, it's pretty innocuous
21:29 yshui`: what is the difference between the "frame counter" in video sync, vs. SBC?
21:30 ajax: nothing, afaik
21:30 ajax: "swap buffer counter"
21:30 yshui`: yeah, weird they don't have sync control
21:31 ajax: i do think the reason they don't have OML_swap_method is that any non-trivial swap-method you could specify with it is then required to be a permanent decision for the whole fbconfig (and any drawable created against it), which limits the optimizations you can do
21:31 ajax: personally i'd be happy to nuke OML_swap_method from mesa
21:32 yshui`: i heard swap_method doesn't make much sense when a compositor is present.
21:40 ajax: it's... icky. like it might be cool if there was a way to convey the desired swap method to the compositor and have that matter
21:40 ajax: but it's kind of bogus to force it to be a property of the drawable instead of something you optimize for per-swap
21:43 yshui`: yeah
21:45 anholt: ajax: arb sync may still be weird, I dunno. but the fence fd stuff in iris should be legit.
21:46 jekstrand: karolherbst: Does your little CTS runner work on the conversions tests?
21:46 jenatali: Probably not, they have a different format
21:47 karolherbst: it does
21:47 jenatali: Oh, cool
21:47 karolherbst: not saying it's pretty though :p
21:47 karolherbst: https://gitlab.freedesktop.org/karolherbst/opencl_cts_runner/-/blob/master/clctsrunner.py#L131
21:47 karolherbst: but in python it's also not that bad to create the list
21:48 karolherbst: doesn't handle "half" but that should be easy to add
21:48 jenatali: karolherbst: I don't think the conversions test can target half
21:48 karolherbst: and it generates some invalid combinations, but the CTS is cool with it
21:48 karolherbst: ahhh
21:48 karolherbst: I see
21:48 jenatali: There's a dedicated test_half for that
21:49 karolherbst: the biggest problem with my runner is, that it depends on the return code, and the CTS isn't consistent with any of that
21:49 karolherbst: so I still need to think of a solution besides fixing the CTS
21:49 anholt: cl cts is not deqp-ish?
21:49 jenatali: The official CTS runner python script looks for ERROR and FAILED output...
21:49 karolherbst: nope
21:49 karolherbst: yeah...
21:49 AndrewR: karolherbst, ok :}
21:49 karolherbst: I think I should do that as well
21:50 karolherbst: the python script was also more to get away from my bash script I had before which was even uglier
21:50 jenatali: karolherbst: I just hit an issue where a CTS run produced garbage output, and I can't tell if it was trying to pass or fail...
21:50 jenatali: E.g. sigwt lmmfas LMMALCHS_T LMMCP_OTPR ufrFL sn tutts asdTsigwt lmmfas LMMUEHS_T
21:50 karolherbst: :D
21:50 karolherbst: jenatali: that's on windows, isn't it? :p
21:50 jenatali: karolherbst: Aye
21:50 karolherbst: also threading
21:50 karolherbst: windows printf isn't thread safe
21:51 jenatali: It looks like characters are missing, I dunno
21:51 karolherbst: so lineendings are global
21:51 karolherbst: or something
21:51 karolherbst: on linux you are guarenteed that printf prints line by line
21:51 karolherbst: so the order is messed up, but lines are consistent
21:51 karolherbst: on windows it's all garbage
21:51 jenatali: Like "etn ihc_e_lg:C_E_LO_OTPR|C_E_OYHS_T" is supposed to be "testing with cl_mem_flags: CL_<something> | CL_<something>"
21:52 karolherbst: lol
21:52 jenatali:shrugs
21:52 karolherbst: maybe something else is happening? :D
21:52 karolherbst: I just know that printf + threading + windws == bad
21:52 jenatali: The real test is does it happen again :P this one's only a half hour to run, so not too bad
21:52 karolherbst: heh
21:52 jenatali: And it finished and didn't happen again, hooray
21:59 jekstrand: Hrm... I seem to have broken char->uchar sat conversions
22:00 jenatali: jekstrand: Shouldn't that just be [0, 127] clamping?
22:00 jekstrand: jenatali: I'm sure it is
22:00 jekstrand: jenatali: I just need to figure out why it's busted
22:00 jekstrand: I'm sure it's simple
22:01 AndrewR: karolherbst, I added NULL as argument, now clinfo says: printf() buffer size 1048576 (1024KiB) - is this correct?
22:01 jenatali: Probably the char I/O rather than the conversion itself
22:01 karolherbst: AndrewR: uhhh, maybe?
22:01 karolherbst: no clue
22:08 jekstrand: Crisis averted...
22:08 ajax: huh. so the classic drivers only expose the 'undefined' oml swap method class.
22:09 ajax: gallium also explicitly exposes 'copy' for some reason. i guess because internally it has to work anyway.
22:09 jekstrand: jenatali: How long should I expect these tests to take?
22:09 jenatali: jekstrand: The conversions tests? Forever :D
22:09 karolherbst: jekstrand: very long if you go for the proper run
22:10 jekstrand: karolherbst: How do I run conversions with your runner?
22:10 jenatali: If you add -w, it's maybe an hour for a full run?
22:10 jekstrand: jenatali: -w?
22:10 karolherbst: yeah
22:10 jenatali: "wimpy" mode
22:10 jekstrand:enables wimpy
22:10 jenatali: It scopes it down to only run like 1/32 of the tests
22:10 karolherbst: ehh...
22:10 karolherbst: I think I disabled conversions... let me see
22:11 ajax: i wonder how widely used it actually is. man i miss google code search.
22:11 karolherbst: jekstrand: clctsrunner.py -w -i conversions
22:11 karolherbst: or without -w if you want to go slower :p
22:12 jekstrand: karolherbst: clctsrunner.py: error: unrecognized arguments: -w
22:12 jekstrand: karolherbst: Do I need a newer version?
22:12 karolherbst: yeah
22:12 karolherbst: I did quite a couple of changes
22:12 karolherbst: even add arguments for overwriting clovers OpenCL versions and stuff
22:13 jekstrand: Ok, running now
22:13 jekstrand: And failing like mad
22:13 jenatali: :(
22:13 karolherbst: mhhh
22:13 karolherbst: do some pass?
22:14 jekstrand: karolherbst: Yeah, a bunch do
22:14 karolherbst: ahh, okay
22:14 jekstrand: But I made some cases assert that didn't look like they did the right thing :)
22:14 karolherbst: ahh
22:15 jenatali: :P
22:16 jekstrand: Like rounding an integer to nearest-even. What even is that?
22:16 jenatali: jekstrand: What's the full conversion?
22:16 jekstrand: convert_uchar_rte( float )
22:17 jenatali: That's float -> uchar
22:17 jekstrand: Yes
22:17 jenatali: So what's 120.5 convert to? :P
22:18 jekstrand: Yeah, but it wasn't doing round_even. It was just hoping that that the conversion did that by magic
22:18 karolherbst: _rte is default for float
22:18 jekstrand: wait... yeah
22:18 jenatali: _rtz is default for float -> int, _rte is default for int -> float
22:18 jenatali: Or float -> float
22:18 jekstrand: Sorry, was thinking rtne it's rtz
22:19 karolherbst: ohh right
22:19 karolherbst: to int it was _rtz...
22:19 jenatali: Which matches NIR's constant folding for conversions, as well as CL's spec
22:24 jekstrand: Ugh...
22:24 jekstrand: <built-in>:1:10: fatal error: 'opencl-c.h' file not found
22:24 jekstrand: Oh, righ... I need to update my LLV
22:24 jekstrand: LLVM
22:27 jekstrand: Ok, now it's really running. :)
22:27 jenatali: Woo
22:28 jekstrand: I don't really get how float->flot rtne is supposed to work...
22:30 jekstrand: At 40%. 100% pass so far
22:32 karolherbst: nice
22:32 karolherbst: jekstrand: ehh.. ignore those which don't make sense
22:32 karolherbst: my runner generates test which are invalid
22:32 karolherbst: but CTS just "passes" them
22:33 karolherbst: so I just didn't care about removing those
22:33 jekstrand: ok
22:33 jekstrand: that's fine
22:33 jekstrand: I'm also running "for real" on my laptop"
22:33 karolherbst: I think they are even valid cl functions? not sure
22:33 karolherbst: they just don't do much
22:34 jenatali: jekstrand: Double -> float rtne makes sense, since double has a mantissa that can represent values that float's can't
22:34 jenatali: jekstrand: Same reason int -> float rtne makes sense, you need to round to the closest representable 24bit value from a 32bit integer
22:36 jekstrand: Pass 945 Fails 51 Crashes 4 Timeouts 0
22:36 jenatali: Not bad
22:37 karolherbst: ui
22:37 karolherbst: nice
22:37 karolherbst: jekstrand: I guess that's all lowered to the normal opcodes or is that with real hw support?
22:38 jenatali: karolherbst: This is with code that we're using for CLOn12, hooked straight into vtn
22:38 karolherbst: anyway, I would like to wire up the real stuff for nouveau, I just need to get a good overview on what we support directly and what not
22:38 jenatali: Slightly refactored and cleaned up
22:38 karolherbst: ahh
22:38 jekstrand: jenatali: I'm done for the night but here's what I've got: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6945
22:38 karolherbst: so, just reusing whatever we have now
22:38 jenatali: Right
22:39 jenatali: jekstrand: Cool, thanks, will take a look :)
22:39 jekstrand: karolherbst: I may wire it up "for real" on Intel as well but we need to get the lowering path working first.
22:39 karolherbst: right
22:39 karolherbst: that's fair
22:39 jenatali: jekstrand: Whoa, didn't realize you actually did hook it up to an intrinsic, that was fast
22:39 karolherbst: do you think it makes sense to move to the intrinsic for vulkan and opengl as well?
22:40 karolherbst: the intrinsic is closer to how we do conversions in codegen as well
22:53 jenatali: That... really wasn't as bad as I expected it to be, cool
23:09 AndrewR: karolherbst, ah, according to this https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2017-November/111296.html ffmpeg need OpenCL images :}
23:17 jenatali: OpenCL images are in the works
23:17 jenatali: Well, for generic Clover at least, can't comment on Nouveau
23:19 AndrewR: jenatali, I currently abuse llvmpipe's OpenCL mode :}
23:19 jenatali: Ah, then you're looking for airlied to hook up images :P
23:21 AndrewR: jenatali, sure, but he is obviously busy - I think I'll just leave xchat open and go to bed for now ....
23:28 airlied: jenatali, karolherbst : with CL images when do we know the image formats and sampler?
23:28 airlied:expects llvmpipe will need some rework here
23:29 karolherbst: formats are runtime only
23:29 jenatali: airlied: Formats are known at kernel enqueue time, as are sampler properties, unless the sampler was declared inline
23:34 airlied: yeah lklvmpipe will have to rebuild shaders at runtime then
23:35 airlied: I suppose I could design a texture block in software, might be useful for gl4/vulkan as well
23:43 jenatali: airlied: Yeah, CLOn12 rebuilds shaders at runtime, since DXIL requires the type information at the shader decl, and we have to lower instructions based on some sampler properties