05:05 bigboo: anholt: happen to be around? was digging around in the v3d code and trying to figure out how the shader state records / uniform buffers interact. afaict, the bo that's mapped in that the ub is written to is life span is ephemeral (it seems tied to the current job). however, the shader state record (which references that ub address) isn't updated on each draw unless various state has been dirtied. i feel
05:05 bigboo: there's something i'm missing there, or else the ub's referenced by the state record seem like they could eventually be trampled when the bo is reused
06:07 jpsollie: Hi everyone, does anyone know about the OpenCL version status of Clover? many documents on the internet are quite old, and they all talk about a WiP status, but how much of the OpenCL 1.1 specification is actually implemented in Clover? which functions are certainly not? any idea?
08:03 pq: imirkin, the same rules for everything. If the driver/hw can change stuff without any glitch (or change in timings?), no need to require ALLOW_MODESET. But I forget, are crtc_x,y,w,h simply the primary plane x,y,w,h? Some hw does not need the primary plane cover the video mode w,h exactly.
08:04 pq: hw that has crtc background color presumably
08:52 emersion: pq: CRTC_{X,Y,W,H} are plane properties indicating the destination geometry
16:05 okias[m]: Is there some possibility how to enforce loading driver only when MESA_LOADER_DRIVER_OVERRIDE is passed? I don't want to get that driver loaded and use swrast instead until it will be stable
16:07 okias[m]: and I don't have PCIids to white/black list it
16:36 MrCooper: okias[m]: you can override the driver in drirc
16:40 okias[m]: MrCooper can this be enforced in mesa.git ?
16:41 okias[m]: I'd be happy if this solution worked together with the code I'm having
16:41 okias[m]: without requiring any external input or after mesa install hook :)
16:42 okias[m]: 00-mesa-defaults.conf is the file, right?
18:04 MrCooper: okias[m]: that or any other file in <prefix>/share/drirc.d/ or /etc/drirc or ~/.drirc
19:16 okias[m]: MrCooper can you point me to some docs, where I can specify for what device use which driver? All I found is assigning apps to device/driver
19:52 okias[m]: btw. does anyone ever managed to run some r300 or r600 on ARM device?
19:52 okias[m]: I quicky searched but no result
19:53 imirkin: iirc there have been some attempts. they generally didn't go very well due to differences in coherency
19:54 okias[m]: yeah, I had similiar feeling. So it doesn't make much sense to build these drivers for ARM anyway. For nouveau tegra X1 device probably works, right?
19:54 okias[m]: s/X1/K1/
19:54 imirkin: works for all the tegras, yeah
19:54 imirkin: and people have been semi-successful in getting a full board up and running too
19:54 imirkin: i forget the details though
19:55 imirkin: (in part because it works on the tegras, so the driver has been updated to work with some of the arm idiosyncracies)
19:55 okias[m]: so, r300,r600,radeonsi can be dropped
19:55 imirkin: probably best to verify with mareko - he'd be aware of the latest and greatest on that front
19:58 okias[m]: okey, I'll wait for him to answer :)
19:59 okias[m]: I recall r300 worked on some powerpc :)
20:00 imirkin: yes, definitely
20:00 imirkin: and radeonsi is, i think, actively supported on power9
20:00 imirkin: nouveau kinda-sorta limps along on BE ppc as well
20:11 HdkR: I tried plugging a Radeon in to one of my ARM boards. Had some issues with unable to allocate PCIe memory space or something :P
20:16 exobuzz: Hi - I'm struggling to verify the mesa 19.3.2 archive - https://mesa.freedesktop.org/archive/mesa-19.3.2.tar.xz.sig - basically via the gbp --uscan tool for package updating - I can't find a valid key on any keyservers for BAD signature from "Dylan Baker <dylan@pnwbakers.com>"
20:17 exobuzz: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 71C4B75620BC75708B4BDB254C95FAAB3EB073EC
20:17 exobuzz: Executing: /tmp/apt-key-gpghome.u7G7owKz2w/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 71C4B75620BC75708B4BDB254C95FAAB3EB073EC
20:17 exobuzz: gpg: key 4C95FAAB3EB073EC: 4 duplicate signatures removed
20:17 exobuzz: gpg: key 4C95FAAB3EB073EC: 5 bad signatures
20:17 exobuzz: gpg: key 4C95FAAB3EB073EC: no user ID for key signature packet of class 13
20:17 exobuzz: gpg: key 4C95FAAB3EB073EC: no user ID for signature
20:17 exobuzz: gpg: Total number processed: 1
20:17 exobuzz: /sorry for spam
20:18 exobuzz: Where can I get his valid public key ? anyone know ?
20:42 imirkin: oh right - that's a big thing on arm - the pcie memory window is too small
21:16 okias[m]: ... huh, I need some help with that drirc. Also I realized. I need it to let register itself with xf96-video-opentegra driver (so tegra_dri.so should load) but then for everything (except when overrided by ENV) use SWRAST (including for xwayland stuff)
21:24 imirkin: okias[m]: you're using pre-K1 tegra, right? (tegra20/30)
21:24 okias[m]: yes
21:24 imirkin: ok cool, just checking :)
21:25 imirkin: i think we might use tegra_dri.so for the tegradrm thing. not 100% sure.
21:25 imirkin: which in turn loads nouveau
21:25 imirkin: which is not what you want
21:32 karolherbst: imirkin: do we have any 3d driver for those chips?
21:32 imirkin: yeah, kusma worked on one iirc
21:32 imirkin: not in master though
21:33 karolherbst: ahh
21:33 karolherbst: I see
21:33 imirkin: no clue as to its state though
21:33 imirkin: my guess is "shy of perfection" :)
21:33 karolherbst: well, but then using swrast is expected
21:33 okias[m]: not much :D
21:33 okias[m]: it's tegra (grate) driver
21:33 karolherbst: right, I remember now
21:33 karolherbst: okias[m]: are you trying to use that one?
21:34 okias[m]: but funny thing is, that we have tablets (tegra20,tegra30) which completly works with Linux (5.5.0-rc6-next).. I have like almost everything working (thanks to digetx)... only 3D is missing
21:34 okias[m]: and these 2011-2013 tables works pretty fast without android. Only since I use 3d accelerated Phoc (Purism stuff), it's slow, because it renders on CPU's
21:35 karolherbst: okias[m]: sure.. but are you testing against a mesa with the grate driver included or unpatched mesa?
21:35 okias[m]: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3456
21:35 gitbot: Mesa issue (Merge request) 3456 in mesa "WIP: grate driver for tegra2 and tegra3 devices" [Opened]
21:35 imirkin: yeah, someone has been doing tons of fixes for tegra tablets
21:35 imirkin: i'm surprised he hasn't picked up grate. maybe he has.
21:36 imirkin: ah yeah. he commented on that merge request
21:36 okias[m]: I trying to get few people from postmarketOS and these places, to just test their tables and improve/fill DTS files for it... and they just work. You pick some DTS, slightly modify it, and it works :D
21:36 karolherbst: uhm.. still uses TGSI? ufff
21:36 okias[m]: (of course thanks to mostly Dimitry's digetx work :) )
21:36 okias[m]: just, initial implementation has been done 2013
21:36 okias[m]: .. so yeah :(
21:37 karolherbst: ohh, I see
21:37 karolherbst: so it's old code already :/
21:37 imirkin: probably easier to stick to tgsi, at least initially. it's a good match for the underlying hw, if it's anything like nv30/nv40
21:37 okias[m]: I tried to watch some XDC talk about NIR conversion, but still not ready to port it :D
21:38 karolherbst: well, tgsi vs nir is only a performance thing these days, where TGSI = slow and nir = fast
21:38 okias[m]: karolherbst well, that code hardly support GL 1.4 for now. But if it get's to gles2.0/GL2.1, it'll be able run glamor and xwayland stuff + normal compositing
21:39 karolherbst: imirkin: even for nouveau, the nir backend is faster as of today even though all codegen is tuned against tgsi
21:40 imirkin: nv50+ is scalar
21:41 karolherbst: doesn't matter
21:41 karolherbst: nir can adjust to scalar or vectorized ISAs
21:41 imirkin: nv30 is basically a direct translation of TGSI -> underlying code
21:41 imirkin: makes for a much simpler compiler.
21:41 karolherbst: sure, just perf is shit
21:41 imirkin: mmmm... dunno about that.
21:41 imirkin: the input programs tend to be tuned for that hw anyways
21:42 imirkin: so it's all well-vectorized
21:42 karolherbst: yeah... maybe if you run older software they tend to run on bad compilers these days so it really might not matter all that much
21:42 karolherbst: but I assume for a more or less recent software stack it will matter
21:43 karolherbst: anyway, would be a fun project to write a nir backend for nv30
21:43 imirkin: more or less recent software won't work at all, since it'll need more recent features :)
21:43 karolherbst: sadly, I won't have time for that
21:43 karolherbst: and that as well, yes
21:44 karolherbst: anyway, the most interesting ability of nir is all the CFG manipulation and related ops, which is something every backend compiler will have huge issues with unless they have a lot of time
21:45 kusma: I
21:45 kusma: I have some experimental beanches for nir in grate
21:46 kusma: But it's hard for me to find time to work on it these days
21:46 karolherbst: yeah... understandable
21:50 imirkin: yeah, that hw bareully supports jumps, so ... cfg isn't a big issue
21:51 karolherbst: since when are real loops supported in glsl btw?
21:51 karolherbst: or did you only had arb shaders there?
21:51 imirkin: since always
21:51 imirkin: but the underlying hw didn't support it
21:51 imirkin: so it was always ok to decline :)
21:51 imirkin: until GLSL 1.30 i suspect
21:51 karolherbst: uff
21:52 imirkin: you can definitely skip it in ES 2.0 -- variable loops that is
21:52 imirkin: non-unrollable loops
21:52 karolherbst: oh well, then it really even matters less
21:53 karolherbst: although I assume these days it's still less work using nir as the backend compiler doesn't need to have that many opts
21:53 karolherbst: oh well
21:55 imirkin: maybe, maybe not
21:55 imirkin: TGSI is closer to the original input
21:55 imirkin: with nir you basically have to have a reordering pass
21:56 okias[m]: kusma if you find some time, I can provide testing + tegra tablets are most close to be complete in terms of HW support :)
21:57 okias[m]: most of HW present on tegra20/30 tablets is mainlined, everything mainly works by just wiring it together in DTS
21:57 kusma: okias[m]: thanks. I have working hardware myself though :)
21:57 okias[m]: so if you spend some time on 3D, it would be one of first full-supported devices :P
21:57 okias[m]: kusma what do you have?
21:58 kusma: okias[m]: I have a few AC100s and a trim-slice
21:59 okias[m]: well, that's low-tier device, I have Nexus 7, which is slightly better, but the top of Tegras is Asus Transformer TF700t (nice display, high-perf cpu, look like good build :) )
22:00 kusma: just to brain-dump a bit; I think the thing that's the most important to make something that works OK-ish, is a working scheduler/register-allocator for the fragment shader. The vertex shader is pretty straight-forward and easy to emit code for, but the fragment-shader is complicated.
22:01 kusma: okias[m]: I also have a TF700T, come to think of it
22:02 kusma: Also an Nvidia Shield portable, but that one isn't set up for development
22:02 okias[m]: one guy managed to run Michal's TF300t kernel (-next linux + few patches) against tf700t (he didn't made panel changes yet, so no lcd, but it's simple panel.. so)
22:03 kusma: I think the TF700t is also not set up for upstream development, just REing
22:04 okias[m]: probably. TFxxx look like weird pieces HW :) but generally they're intercompatible a lot
22:04 kusma: gotta go now, though. okias[m], I'll let you know if I find some time at some point, but I wouldn't hold my breath.
22:04 okias[m]: Thank you for your work in general kusma :)