<anholt>
jekstrand: yeah, I've been thinking I need to just pick up some systems to do manual ci for crocus, since Intel isn't participating on gitlab CI.
<airlied>
ngcortes: is it a big task to make that job public?
<airlied>
any maybe have a branch that I can have run that in advance?
<ngcortes>
airlied, we've actually got an outage on the public results site currently that we're working on. I'll make an announcement
* airlied
just noticed, no hurry, just at least for crocus hardly anyone inside intel is working on it :-P
pnowack has quit [Quit: pnowack]
ngcortes has quit [Remote host closed the connection]
<airlied>
jekstrand, Kayden : btw if either of you could glance at the internal URL above, and let me know if there are any big problems :-)
<jekstrand>
anholt: Yeah, looks like IVB and SNB systems are about $100/each on eBay. Wouldn't be too bad.
iive has quit []
<airlied>
anholt: would they just be non-default optional runners in gitlab?
<anholt>
airlied: that's my thought.
<jekstrand>
x200's, however, those are more expensive 'cause libreboot.... *sigh*
<airlied>
anholt: desktop or laptop?
<jekstrand>
anholt: Do the old Haswell chromebooks have the fancy boot stuff that makes them reliable to put in CI?
<anholt>
jekstrand: could be worth a look, though generally they have tremendously slow CPUs.
<anholt>
it's a lot nicer to have a high end cpu for getting through CI.
<jekstrand>
True
* anholt
has some nice core 2 quads in i915g ci box and the r600/nouveau/etc testing box.
<jekstrand>
Especially when you can actually do GL 4.6. THere's a lot to CI there.
* airlied
might have some ilk desktops in the office if I ever get back in there
<jekstrand>
I hope we never see a new Atom part without HW FP64. That would take so incredibly long to do a full GL 4.6 run on....
* anholt
finds a baytrail laying around. single thread, oof.
ybogdano has quit [Ping timeout: 480 seconds]
<alyssa>
jekstrand: add to list of reasons why I hope GL 4.x Mali doesn't become a thing
<jekstrand>
:)
<jekstrand>
Zink+panvk
<bnieuwenhuizen>
just implement Vulkan CTS and then let Mike deal with all the GL pieces
<bnieuwenhuizen>
you'd think VK CTS would catch up eventually
<bnieuwenhuizen>
not that VK CTS is fast ...
ngcortes has joined #dri-devel
<alyssa>
jekstrand: zink+panvk would be GL3.1 at best
<alyssa>
since we don't support GS/tess in any pan*
<alyssa>
strictly speaking, neither is /hard/, it's just a *ton* of typing for check box features that won't ever perform well on our hardware
<alyssa>
....Is gs/tess mandatory for vk?
<idr>
I don't think so.
<idr>
I think that was one of the lines in the sand the mobile vendors had.
<alyssa>
*nod*
<alyssa>
looks like both are feature bits, meaning neither is mandatory
<alyssa>
Though I am curious which vendors aren't shipping gs/ts on vk, given they're mandatory in es32
soreau has joined #dri-devel
<anholt>
airlied: ok, should have a beefy hsw laptop for ci by christmas.
<alyssa>
hsw isn't already in ci?
<anholt>
not in gitlab, no
<anholt>
I've got some more optimization I noticed for ntt that would also help crocus-era HW, but I need to be able to actually test it.
<HdkR>
jekstrand: There should be Gracemont Atom with Xe at some point right? Does low end Xe support FP64?
<HdkR>
At least that case will be significantly faster than Tremont or Goldmont :P
columbarius has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
<jekstrand>
HdkR: They removed it on ICL :-(
<jekstrand>
alyssa: GS/tess is interesting. I think there's a lot of pressure to support it even if it sucks. Especially if you want to support ANGLE or Zink for GL on Vulkan.
<bnieuwenhuizen>
Still surprised that AMD hasn't done that yet with the RDNA/CDNA split for graphics vs. compute
<HdkR>
jekstrand: That's a sad time
<ajax>
do we have any fp64 shaders in shaderdb?
jhli has quit [Remote host closed the connection]
<Kayden>
nope.
<alyssa>
jekstrand: Sigh
<idr>
anholt: !14218 should help your crocus efforts.
<alyssa>
crocus pocus
mbrost has quit [Ping timeout: 480 seconds]
<idr>
ajax: If you can find an app that uses fp64 so that we could put it in shader-db...
boistordu has quit [Ping timeout: 480 seconds]
<idr>
...we'll probably have to cry ourselves to sleep.
<alyssa>
ajax: If you find such an app, please send a patch upstream to make it not.
<idr>
+1
<ajax>
luls
<ajax>
possibly simpler to just run sed over existing float32-using shaders and keep that as a separate suite
<ajax>
the idea is just to get some coverage for it on the theory that any optimization is going to be super visible there
<idr>
Well...
<idr>
The problem is that I don't want an opt that hurts (nonexistent) fp64 apps but helps to fp32 apps to be penalized... or require extra scrutiny.
<ajax>
sure, that makes sense
<ajax>
kind of what i meant by "keep that separate"? you wouldn't want to care too much about synthetic fp64 cases normally, but being able to verify that you don't ruin lowered-fp64 output would be useful
<idr>
Fair.
<ajax>
just thinking out loud, here
<idr>
And I had something like that when I was doing the optimizations specifically for the soft-fp64 code last year (or whenever it was).
<idr>
Two years ago?
<idr>
Anyway... I dumped a bunch of the shaders from the CTS to do shader-db runs on.
<idr>
Because the goal was to reduce spilling in the CTS to reduce CTS runtime. :facepalm:
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
zip100 has joined #dri-devel
slattann has joined #dri-devel
ella-0 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
<ishitatsuyuki>
I wrote a piece on using perfetto and AGI layers to profile CPU overhead. It's vendor agnostic so mesa might not be the exact place this doc should be included, but I'll submit a MR if you see fit
mareko has quit [Remote host closed the connection]
mareko has joined #dri-devel
mslusarz_ has joined #dri-devel
dri-logg1r has joined #dri-devel
marcheu has quit [Ping timeout: 480 seconds]
mslusarz has quit [Remote host closed the connection]
dri-logger has quit [Ping timeout: 480 seconds]
dri-logg1r has quit [Remote host closed the connection]
dri-logger has joined #dri-devel
mareko_ has joined #dri-devel
mslusarz_ has quit [Read error: Connection reset by peer]
mslusarz has joined #dri-devel
mareko has quit [Read error: Connection reset by peer]
slattann has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
heftig[m] has joined #dri-devel
Lucretia has quit []
Lucretia has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
idr has quit [Quit: Leaving]
Company has quit [Ping timeout: 480 seconds]
mareko_ is now known as mareko
<mareko>
airlied: that's fine, maybe we can use the dispatch table for other render modes later
<mareko>
airlied: actually you can keep DrawGallium as-is for now
<mareko>
it probably needs more thought
mbrost has joined #dri-devel
<cmarcelo>
is GL/internal/dri_interface.h a "public API" or we have room to fix names there?
sdutt_ has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<mareko>
cmarcelo: it's public
<mareko>
Gelsinger is a funny character, first dissing TSMC, then praising it
mclasen has quit [Ping timeout: 480 seconds]
mattrope has quit [Read error: Connection reset by peer]
sadlerap1 has joined #dri-devel
sadlerap has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<ajax>
cmarcelo: the only other consumer is xserver, and ideally that's going to stop being true sometime in 2022
<ajax>
cmarcelo: what are you looking to fix in it?
kem has quit [Ping timeout: 480 seconds]
<cmarcelo>
ajax: well. not sure if is worth fixing, but while reviewing EGL_EXT_protected_content series from dj-death noticed that the DRI symbol we expose for EGL_EXT_protected_surface is... __DRI_..._PROTECTED_CONTENT, forcing the other extension to pick a different name.
<ajax>
cmarcelo: enh. feel free to rename that one, mesa builds against its own internal copy of that header (or is damn well meant to) and xserver doesn't use __DRI2_RENDERER_QUERY yet (and should not, anything along those lines is better done by finishing porting xserver/glx the rest of the way to egl)
<cmarcelo>
ajax: tks. left a note to Lionel.
<airlied>
anholt: yeah there is at least one fix out there for a leak in progress I think
<airlied>
anholt: is CTS asan clean?
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
marcheu_ has quit [Remote host closed the connection]
marcheu has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
mszyprow has joined #dri-devel
mlankhorst has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
jkrzyszt_ has joined #dri-devel
<javierm>
tzimmermann: the nomodeset series are more controversial than I thought. I will only include pci and platform drivers that have DRIVER_MODESET in v2
<javierm>
tzimmermann: did you see pinchartl's comment on doing it in drm_dev_alloc() ?
<javierm>
that's was the first approach that we discussed but IIRC jani said that wouldn't like the i915 driver to wait until probe to fail if could be done earlier at module init time
<javierm>
or maybe I'm misremembering
tursulin has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
alexeymin has quit [Quit: No Ping reply in 210 seconds.]
alexeymin has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
<hakzsam>
anyone know how to fix "meson.build:1005:6: ERROR: Could not get define 'ETIME'" when building mesa?
pcercuei has joined #dri-devel
<emersion>
hakzsam: are you building on freebsd?
<hakzsam>
no, archlinux
<emersion>
well that's weird
<emersion>
this doesn't cause issues on my arch system
<tzimmermann>
javerm, as you mentioned in you mail, drm_dev_alloc() is too late
camus has quit [Read error: Connection reset by peer]
<tzimmermann>
mripard, may i ask you for another review? yesterday i accidentally sent you to v1 of the ast patches. v2 is the same except for a trivial patch. no changes, just moving code around. may i ask you to look at https://lore.kernel.org/dri-devel/20211206091125.29501-4-tzimmermann@suse.de/ as well? sorry for the mistake
<javierm>
tzimmermann: we still will have to open code it in some drivers that have custom init/exit but those could be cleaned up later. Specially once we introduce a drm module parameter to override nomodeset
<tzimmermann>
javierm, the pci code needs protection with #if defined(CONFIG_PCI)
<tzimmermann>
the defines should be called drm_module_pci_driver(), drm_module_platform_driver(), etc
<tzimmermann>
javierm, yeah it's probably best to get the core macros in place and convert a few trivial drivers. the other drivers can follow later
<javierm>
tzimmermann: that's how I called.
<tzimmermann>
the pci macro looks incorrect
<mripard>
tzimmermann: ack
<tzimmermann>
mripard, thank you
<javierm>
tzimmermann: oh, it's a typo because I so far converted the platform drivers. The function name in the comment was correct :)
<tzimmermann>
ah, ok
Lucretia has quit []
gpuman has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: btw, I didn't guard against CONFIG_PCI because <linux/pci.h> already has stub functions when not defined
<tzimmermann>
ok, that's even better
<tzimmermann>
but in that case, i'd still group helpers and macros by bus. seems more readable to me
<mripard>
tzimmermann: and ack for merging the p030 patches from yesterday and making the refactoring you suggested later ?
<tzimmermann>
mripard, yes.
Lucretia has joined #dri-devel
<javierm>
tzimmermann: Ok, I followed what other headers did but will group by bus
<tzimmermann>
javierm, really ? which headers?
Lucretia has quit [Read error: Connection reset by peer]
<javierm>
granted it's for the same platform bus but still followed that convention
<javierm>
but I was indeed torn on whether group by bus or not, so I'll follow your suggestion
<tzimmermann>
javierm, i see. i wouldn't mix differnet busses. if i write a pci-based drm driver and want to know what that macro does, i'd want all relevant code in one place.
<javierm>
tzimmermann: makes sense
<tzimmermann>
thanks
Lucretia has joined #dri-devel
rasterman has joined #dri-devel
pnowack has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
thellstrom1 has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
camus has joined #dri-devel
somkls^ has quit [Ping timeout: 480 seconds]
camus1 has quit [Read error: Connection reset by peer]
<pinchartl>
robher: is there a way to express mutual exclusion between two properties in a yaml schema, when one of the two properties is a pattern property ?
MrCooper has quit [Remote host closed the connection]
<robher>
pinchartl: not yet because there is not any patternRequired or such. Something like that is on the json-schema radar though. Maybe you could do it with an if/then and unevaluatedProperties. if not required prop, then patternProperties ...
MrCooper has joined #dri-devel
<robher>
pinchartl: You should join #devicetree on libera.chat and ask DT questions there...
<pinchartl>
robher: thanks
<pinchartl>
indeed, it's a bit out of topic here
OftenTimeConsuming has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
JoseExposito has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
jose has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
jose has quit []
JoseExposito has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
JoseExposito has quit [Quit: JoseExposito]
JoseExposito has joined #dri-devel
JoseExposito has quit []
JoseExposito has joined #dri-devel
JoseExposito has quit [Remote host closed the connection]
phinxy has joined #dri-devel
x512 has joined #dri-devel
x512 has quit []
x512 has joined #dri-devel
<x512>
Is it possible to avoid use of libsync fro syncobj and implement sync_accumulate only with libdrm syncobj handles?
<emersion>
what is libsync?
<x512>
Part of Mesa. src/util/libsync.h It use SYNC_IOC_* ioctl's.
tlwoerner has quit [Ping timeout: 480 seconds]
<anholt>
X512: You need those ioctls for merging syncs.
tlwoerner has joined #dri-devel
<x512>
Maybe some workaround exists? For example waiting for syncobj in code. I am implementing libdrm compatibility layer in userland and there are no real fds, only handles.
<anholt>
airlied: yeah, looking at turnip, it seems the VK CTS itself is awful at asan.
<anholt>
X512: you're going to need to emulate sync fds.
<x512>
It implements amdgpu drmIoctl hook in userland in RadeonGfx GPU driver process. It worked fine before with older Mesa function, but now syncobj API become mandatory. It is currently not implemented in RadeonGfx.
<x512>
It can't work with fds, because fd is kernel object and driver implementation is fully in userland.
mszyprow has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
X512: is the issue just accumulate_sync or also any other direct libdrm usage? ( like in src/vulkan/runtime/vk_drm_syncobj.c)
<x512>
Only accumulate_sync .
<x512>
For everything other syncobj handles seems enough to run Vulkan demos.
<robclark>
you can poll() and ioctl() on fence fds.. I don't think fake fds in userspace will really work in the general sense.. but might be enough to get some demos working
<x512>
drmSyncobjExportSyncFile currently do open("/dev/zero", O_CLOEXEC). Only handles are supposed to be functional for now.
<x512>
Why there are no symcobj merge API for handles?
<x512>
fd should be not needed for process local rendering.
<bnieuwenhuizen>
for newer kernels I might be able to do something with timeline syncobj, but for older kernels accumulate_sync is the only way I know of to take the intersection of two syncobj
<robclark>
I mean, I guess you could create some shim API for various syscalls on a fence fd.. not _really_ sure that should be in libdrm (I don't think we use libdrm when building driver to run on android vendor kernel, for example).. but if there is build option already for mesa on haiku, I guess you could just make libsync.h do the right thing, whatever that is, for haiku?
<alyssa>
You could add a shim
<alyssa>
for the syscalls on the fence
<alyssa>
in libdrm
<bnieuwenhuizen>
FWIW I think long term the right solution might just be some kind of haiku winsys, but on the radv side I think we'd need to pull a bit more out of the winsys and into radv for that to make sense
pendingchaos has quit [Remote host closed the connection]
pendingchaos has joined #dri-devel
<x512>
radv_amdgpu_cs_submit_zero directly calls syscalls on fd such as close(). Maybe some other places exist.
<robclark>
quite likely that they do.. being an fd is baked into the api
<airlied>
bnieuwenhuizen: we should add a syncobj accumlate api if one doesn't exist
<airlied>
esp if ppl are doing syncobj->fd, accum, fd->syncobj or something like that
<bnieuwenhuizen>
airlied: that dance is what I did
<bnieuwenhuizen>
I think with timeline syncobj I can just do it by adding each of the sources as points and then transferring the last point to the output
<airlied>
yeah I think we should avoid roundtrips through sync fence where we can
Lightsword_ is now known as Lightsword
<bnieuwenhuizen>
agreed, just did my initial impl with the roundtrip so it works with old kernels
<airlied>
maybe if the timeline path is common then it's fine to leave
<bnieuwenhuizen>
airlied: we would use it for binary syncobj too, just some driver internal syncobj needs to have timeline syncobj capabilities, which only works if the kernel supports timeline syncobj
<jekstrand>
dj-death: I think that probably gets us the best of all worlds. It also fixes a potential race when timeline semaphores are used.
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
mlankhorst has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Read error: Connection reset by peer]
pendingchaos has joined #dri-devel
sneil has quit [Quit: Leaving]
sneil has joined #dri-devel
<airlied>
anholt: what is g41? 965g?
camus1 has joined #dri-devel
<jekstrand>
g41?
camus has quit [Remote host closed the connection]
<airlied>
the chipset they have for crocus tests
mlankhorst has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<anholt>
965, yeah.
<anholt>
eaglelake if that helps.
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #dri-devel
isinyaaa has quit [Quit: WeeChat 3.3]
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
pendingchaos_ has quit []
<airlied>
anholt: I think we were mostly 965 compatible in piglit when I last looked
<airlied>
but it's been a while, if I get some time next week I'll boot the ole 965
gouchi has quit [Remote host closed the connection]
<anholt>
piglit did look pretty good.
pendingchaos has joined #dri-devel
<anholt>
I can get you a comparison with release 965 if that would help
danvet has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
<anholt>
airlied: there you go, all the piglit regressions noted in the fails file now
<anholt>
for gles2, crocus only fixes things.
<anholt>
(and i965 has the loop flakes, too)
<ajax>
is #3437 still the preferred place for freedreno flake reports?
<anholt>
yeah, I guess. or just shove it in an mr and we can auto-assign to marge
<ajax>
noted in !14221
<anholt>
interesting. that one's never shown up as a flake status, but my history says I've gone looking for it in my CI flake reports before.
<graphitemaster>
Has anyone ever noticed how the NV proprietary shader compiler will replace a non-dynamically-uniform index into a FS input (output from the VS) with a forever loop that checks the first invocation until the index matches?
<graphitemaster>
Found a way to trigger (with UB) a lockup with this trick
<graphitemaster>
I'm kind of impressed they do that.
rasterman has joined #dri-devel
Hi-Angel has quit [Ping timeout: 480 seconds]
cphealy has quit [Quit: Leaving]
<jekstrand>
It's a pretty standard trick for dealing with non-uniform things
cphealy has joined #dri-devel
mszyprow has joined #dri-devel
quantum5_ has quit []
quantum5 has joined #dri-devel
<alyssa>
graphitemaster: That's less obnoxious than what the Mali compiler does
<alyssa>
giant if-else chain comparing the invocation id with constants 0, ..., n - 1 for warps of n threads
<alyssa>
it worked ok when they only do 4 threads in a warp.......
<alyssa>
*did
gawin has joined #dri-devel
<alyssa>
Now they're up to 16 threads in a warp.....
x512 has quit [Remote host closed the connection]
<graphitemaster>
alyssa, wow
<gawin>
bonjour, where can I check correct mapping PIPE_FORMAT <--> ISL_FORMAT? (or it doesn't matter if you stick to one convention everywhere?)
<gawin>
(for example using ISL_FORMAT_R16_FLOAT for PIPE_FORMAT_L16_FLOAT fixes spec@ext_packed_float@query-rgba-signed-components on crocus though not sure if it's right solution)
<Kayden>
crocus_format.c and iris_format.c do that mapping
<Kayden>
luminance/intensity/alpha (L/I/A) formats are fundamentally stored as 1 component data, but when samples from, return that data as XXX1/XXXX/000X, respectively
<Kayden>
the hardware has e.g. ISL_FORMAT_L8_UNORM type formats which make the sampler read the 1 component image and return it in that format for you
<Kayden>
but they are not the most efficient, because the sampler upconverts to RGBA internally pretty early, and thus stores it in caches, utilizes bandwidth, etc, for a 4-component format
<Kayden>
which is why on iris we try to use the R* (red) formats instead, with texture swizzling to do the right data layout (SURFACE_STATE Shader Channel Select fields)
<Kayden>
Haswell has native texture swizzling support, but older hardware covered by crocus does not, and emulates texture swizzling via shader code and shader recompiles.
<Kayden>
you may just want to use the native L/I/A formats there
<Kayden>
there are also issues with rendering to said formats. A8_UNORM is required to be renderable. I don't think most of the others are
<Kayden>
I believe rendering to A8_UNORM, for example, you write the color into the .A channel, while .RGB is ignored as garbage values
<anholt>
Kayden: seems like we should make st_format.c pick R at least as a fallback for L instead of RGBA and emit any necessary fixups.
<Kayden>
unfortunately the texture swizzling can't handle swapping between RGB and A, because that gets into color blending issues
<Kayden>
that would be great, but I seem to recall that there's a reason why that was painful