ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<marex>
alyssa: surely enough, neverball with nir on mesa 21.2.3 is broken on etnaviv again ... sigh
<alyssa>
piglit-traces?
<anarsoul>
marex: are you fixing it for fun? or you company really wants to run neverball on etnaviv? :)
<alyssa>
I'm a believer in not shipping known broken code..
<marex>
anarsoul: I'm fixing it to learn something new and partly unrelated, i.e. for fun
<marex>
alyssa: I just ran the thing on mx8mm, once I have a bit of time again, I'll dig in and see what's going on
<marex>
the corruption looks familiar though
nchery has quit [Quit: Leaving]
aperezdc has joined #dri-devel
aperezdc is now known as Guest2150
columbarius has joined #dri-devel
sarnex has quit [Quit: Quit]
co1umbarius has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
yoslin_ has quit []
columbarius has quit [Ping timeout: 480 seconds]
yoslin has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
MatrixTravelerbot[m] has joined #dri-devel
cwfitzgerald has joined #dri-devel
columbarius has joined #dri-devel
Dylanger has joined #dri-devel
pushqrdx has quit [Quit: pushqrdx]
kallisti5[m] has joined #dri-devel
<Company>
I am very pleased that Mesa can do everything but I can make it hide that skill and throw GL_INVALID_EVERYTHING at me because the spec doesn't want it to do that
<Company>
I just wish the spec writers would smoke a little less crack
ybogdano has quit [Ping timeout: 480 seconds]
ella-0[m] has joined #dri-devel
unrelentingtech has joined #dri-devel
xerpi[m] has joined #dri-devel
camus has joined #dri-devel
LaughingMan[m] has joined #dri-devel
Tooniis[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
Company has quit [Quit: Leaving]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<airlied>
agd5f: drm/amd/display: Fix detection of 4 lane for DPALT (5a1fef027846e7635b9d320b2cc0b416fd11a3be) wtf is the MIN definition doing in there, esp upstream
<airlied>
agd5f: also 13900e6fde3f91ea34a586002d592a2b20e1142e adds #define YELLOW_CARP_B0 0x20
<airlied>
but elsewhere that is 0x19
<airlied>
that commit doesn't explain why it defines that
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<agd5f>
airlied, I'll get those cleaned up. 0x19 is the external offset for B0, the silicon revision from the register is 0x1 so 0x19 + 1 = 0x1a
camus1 has joined #dri-devel
<agd5f>
the random 0x20 looks like an accidental hunk that was leftover from debugging
<agd5f>
someone was probably thinking in decimal
camus has quit [Ping timeout: 480 seconds]
<airlied>
agd5f: might be good to push back on a bit on review quality inside display team, I'm not sure a lot of those patches would get past checkpatch to well
macromorgan is now known as Guest2169
macromorgan has joined #dri-devel
idr_ has joined #dri-devel
sdutt_ has joined #dri-devel
zack__ has joined #dri-devel
Guest2169 has quit [Read error: Connection reset by peer]
zrusin has quit [Read error: Connection reset by peer]
sdutt has quit [Read error: Connection reset by peer]
linearcannon has quit [Ping timeout: 480 seconds]
idr has quit [Ping timeout: 480 seconds]
linearcannon has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost_ has quit [Remote host closed the connection]
rcf has quit [Quit: WeeChat 3.1]
aravind has joined #dri-devel
robertmader[m] has joined #dri-devel
Duke`` has joined #dri-devel
tomba has joined #dri-devel
linearcannon has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
linearcannon has joined #dri-devel
jewins1 has joined #dri-devel
jewins has quit [Remote host closed the connection]
mattrope has quit [Ping timeout: 480 seconds]
sdutt_ has quit [Read error: Connection reset by peer]
jenatali has joined #dri-devel
nielsdg has joined #dri-devel
YaLTeR[m] has joined #dri-devel
idr_ has quit []
camus has joined #dri-devel
jewins1 has quit [Ping timeout: 480 seconds]
MrR[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
Eighth_Doctor has joined #dri-devel
pnowack has joined #dri-devel
chema has joined #dri-devel
unsolo_ has joined #dri-devel
thellstrom has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
unsolo_ has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
danvet has joined #dri-devel
hansg has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
shashank_sharma has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
<hikiko>
jekstrand, crocus was working well a few weeks ago, but 2 days ago I've found some compile errors (MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13236) and after I rechecked I could only run it as root, so I am debugging it. The initial plan was to check ext external objects on it but I am still porting/waiting for review for the vulkan tools that are needed (loader, validation layers, piglit etc)
<hikiko>
hmm, not even as root :) jekstrand I just realized that root was simply running i965 :p sorry. Anyway, I am debugging it, there's a segfault from a c++ constructor (std::ofstream somewhere) so I believe it's something like linking with system's c++ because of gcc but searching the headers in clang's c++ implementation that is default on freebsd... if the c++ class differs in size or something like that it makes sense to crash I think (not sure
<hikiko>
:D, debugging)
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
DrNick has joined #dri-devel
DrNick is now known as Guest2186
elongbug has joined #dri-devel
lynxeye has joined #dri-devel
danylo has joined #dri-devel
itoral has quit [Remote host closed the connection]
<hakzsam>
jekstrand: any reasons why ANV doesn't use vk_image_view_init()?
<dj-death>
hakzsam: it uses vk_image_view_create() which calls init
<hakzsam>
ah ok
HayashiEsme[m] has joined #dri-devel
pcercuei has joined #dri-devel
Ahuj has joined #dri-devel
enick_765 has joined #dri-devel
fluix has quit [Remote host closed the connection]
rcf has joined #dri-devel
shashank_sharma has quit [Ping timeout: 480 seconds]
fluix has joined #dri-devel
go4godvin has joined #dri-devel
go4godvin is now known as Guest2190
gawin has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Guest2150 is now known as aperezdc
vivijim has joined #dri-devel
Strit[m] has joined #dri-devel
orbea1 has joined #dri-devel
gagallo7[m] has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
Guest2190 is now known as go4godvin
T_UNIX has joined #dri-devel
zzoon[m] has joined #dri-devel
ServerStatsDiscoverertraveler4 has joined #dri-devel
<emersion>
danvet: any idea why drm_atomic_plane_check returns ENOSPC instead of EINVAL when the source coords are incorrect?
<emersion>
hm there's also ERANGE
<vsyrjala>
because why not
<emersion>
for invalid CRTC coords
<emersion>
because it makes it complicated for user-space to tell "real" failures apart from "normal" ones
<emersion>
TEST_ONLY is useful to indicate whether a configuration is possible or not
<emersion>
if i have to add 999 cases for all possible error codes for "invalid config", it's not helpful
<vsyrjala>
all i know it has helped many times when people come here asking "why i get ENOCPS" i can immediately tell them to fix their coordinates
<emersion>
this doesn't scale at all
<emersion>
we have just a few error codes
<vsyrjala>
sure. errno is not greate
<vsyrjala>
great
<emersion>
and many checks
<emersion>
also none of this is docuemnted
<vsyrjala>
i suspect you can probably get EINVAL for a ton of "real" errors too. so i don't think you can distinguish stuff based on that
<emersion>
so what's the right thing to do for user-space?
<emersion>
never trust errno?
<vsyrjala>
also for TEST_ONLY there sort of shouldn't be any "real" errors anywya since it doesn't talk to any hw/etc.
<vsyrjala>
or maybe i don't understant what is real and what is not?
<emersion>
out of memory is a runtime error
<emersion>
EINVAL is a check error
<emersion>
i want to catch check errors only
<vsyrjala>
i don't think you can trust it that much
<vsyrjala>
-ENOMEM maybe
<emersion>
there are other runtime errors
<vsyrjala>
which ones are relevant for TEST_ONLY?
<emersion>
-EDEADLK, -EINTR, -EAGAIN or -ERESTARTSYS
<emersion>
-EIO also
<vsyrjala>
-DEADLK never leaves the kernel at least. -EINTR is the normal thing
<vsyrjala>
ho can you get -EIO from TEST_ONLY?
<vsyrjala>
-EAGAIN sounds like something TEST_ONLY should not give
<emersion>
it's documented as something drivers can return
<vsyrjala>
-ERESTARTSYS.. wasn't that just the internal -EINTR? or am i misremembering this?
<emersion>
also confusingly ENOSPC is returned by real commits for "out of vram"
<vsyrjala>
i'd say if driver gives -EIO for TEST_ONLY there's something wrong in the driver
<emersion>
which makes a whole lot more sense than "invalid src copords"
<emersion>
coords*
<vsyrjala>
well, it's not got enough space in the fb for the thing it's trying to scan out. not great but sort of accurate
<vsyrjala>
anyywa, if you insist i guess you could try to change it. i won't object too much. hopefully no one is relying on it as abi
<vsyrjala>
just means i have to ask for the drm.debug dmesg every time from now on :P
<emersion>
well my main grudge is that nothing is defined
<emersion>
i guess i'll just expand my magic list of errnos
<vsyrjala>
i think the definition is "if you get <0 you try something different
boistordu has joined #dri-devel
<pq>
emersion, are you trying to figure out the difference between "hw/driver does not support this" and "my code is driving KMS wrong"? Or what's the real vs. check error thing?
<emersion>
pq, i'm trying to figure out whether the kernel asks me to try something different, or whether something else went wrong
<emersion>
"invalid configuration" vs. "runtime error"
<emersion>
stop is like "page flip failed, let's retry in 16ms or so"
flacks has quit [Quit: Quitter]
<pq>
so on runtime error, you do not want to try downgrading your configuration, you just want to skip and try again later?
<emersion>
yeah
flacks has joined #dri-devel
<pq>
why do you do not want to try downgrading?
<emersion>
consistently returning EINVAL would also help figuring out the error cases in non-test atomic commits
<emersion>
if the system is under low memory, hammering the kernel doesn't seem like a good idea
<emersion>
and making errors silent doesn't seem like a good idea
<emersion>
there are also errors which are definitely user-space messing up
<emersion>
like EPERM
<pq>
I kind of see the point about low memory, but I'm not sure that would make any difference when the situation is already that bad.
<emersion>
ignoring things like EPERM ends up with user-space logging nothing, and saying "i haven't found any configuration"
<vsyrjala>
i guess a specific errno for "you're using the api wrong" might be interesting
<vsyrjala>
vs. you just hit some limitation of the system
zzag[m] has joined #dri-devel
hikiko has quit [Quit: Leaving!]
<pq>
Yeah, error codes for "you're using the API wrong", "hw/driver cannot do what you ask", "no resources to process your request", and "permission denied" could be useful.
hikiko has joined #dri-devel
hikiko has quit []
hikiko has joined #dri-devel
<pq>
A new flag to atomic commit "pls give me meaningful error code in this extra field, kthx"? :-)
<vsyrjala>
does errno have enough sensible vlaues for that? i have my doubts
<pq>
does not need to be errno
<vsyrjala>
well, if we start thinking of returning useful errors, maybe there should just be a string passed back that explains things
<pq>
a machine readable string? or just for human consumption?
<pq>
i.e. uABI or not? (until it becomes uABI) :-p
<vsyrjala>
human. i wouldn't want an abi that is so easy to break. but yeah, danger is that someone would parse it anyway and then it's abi
<pq>
DRM flight recorder should be enough for the human readable thing
<vsyrjala>
we should change every string every kernel release to make sure you can't use it like that :P
<vsyrjala>
ernno is definitely annoying. a few kinda generic things, and the metric boatload of some specific ancient unix network/fs/etc. stuff
<pq>
oh, EOPNOTSUPP and ENOTSUP are the same code, and I suppose that's reserved the generic ioctl() to say no such ioctl?
<Ristovski>
There is a mesa radeonsi commit stating to disable SDMA on "gfx6-7 and gfx10.3" but IIRC GFX6 does not have SDMA? But then AMDs OpenCL programming guide states "Southern Island devices have two SDMA engines that can perform bidirectional transfers.."
<Ristovski>
So I guess question: Does SI/GFX6 have SDMA or not?
thellstrom has quit [Remote host closed the connection]
neobrain[m] has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<Ristovski>
Grepping around mesa seems to indicate that GFX6 indeed does not have SDMA
shashanks has joined #dri-devel
hikiko has quit [Quit: Leaving!]
hikiko has joined #dri-devel
hansg has quit [Quit: Leaving]
APic has quit [Quit: leaving]
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
APic has joined #dri-devel
RAOFhehis[m] has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
PiGLDN[m] has joined #dri-devel
hikiko has quit [Quit: Leaving!]
hikiko has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
aura[m] has joined #dri-devel
Ahuj has joined #dri-devel
hikiko has quit []
hikiko has joined #dri-devel
tintou has joined #dri-devel
hikiko has quit [Quit: Leaving!]
hikiko has joined #dri-devel
hikiko has quit []
hikiko has joined #dri-devel
hikiko has quit [Quit: Bye!]
hikiko has joined #dri-devel
giggi has joined #dri-devel
<agd5f>
Ristovski, it has a similar dma engine, the predecessor to sdma
<Ristovski>
I see
<agd5f>
Ristovski, the older dma engine exists on r6xx-SI
<Ristovski>
agd5f: Is that used for the si_dma_* stuff in mesa?
<Ristovski>
Anyway, my curiosity was initially from "radeonsi: make the DRI_PRIME dGPU -> iGPU copy async", since it has a ">= GFX7" check
<agd5f>
Ristovski, I think there used to be code for SI and easier in mesa. Not sure if it's still there or not
Ahuj has quit [Ping timeout: 480 seconds]
<agd5f>
airlied, ack
<Ristovski>
agd5f: Is the old DMA synchronous only?
sdutt has joined #dri-devel
<agd5f>
Ristovski, no, separate engine just like SDMA
<agd5f>
fundamentally no different from SDMA, just older hardware block, different packet format, etc.
<Ristovski>
Oh I see. Then I suppose it's only missing an implementation to make dGPU->iGPU copy async for GFX6?
<Ristovski>
agd5f: Thanks! I'll see if I can hack something up when I have the time
<Ristovski>
Seems like lots of stuff has changed since the last time I did anything mesa-related
Ahuj has joined #dri-devel
<agd5f>
Ristovski, kernel driver uses it pretty extensively as well if you need further references
<Ristovski>
Sweet! That will sure be helpful
<Ristovski>
agd5f: Hmm actually, is there a list of unimplemented features for GFX6 in general? One I know about is VCE from the old `radeon` missing in `amdgpu`, but not aware of anything else
unsolo_ has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
<agd5f>
I can't think of anything else off hand
Newbyte has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
hansg has joined #dri-devel
Ahuj has joined #dri-devel
atulu[m] has joined #dri-devel
Venemo_ has joined #dri-devel
Venemo_ has quit []
kmn has quit [Quit: Leaving.]
Venemo has joined #dri-devel
Venemo is now known as Guest2215
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
Venemo has joined #dri-devel
<Venemo>
agd5f: did you guys figure out the SDMA hang issues?
Company has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
yogesh_m1 has quit [Ping timeout: 480 seconds]
cleverca22[m] has joined #dri-devel
orbea1 has quit []
orbea has joined #dri-devel
<danvet>
emersion, vsyrjala, pq should at least document stuff
<danvet>
and for more detailed error codes I think one idea was to have a property and suggested value or something
<danvet>
optionally at least, since sometimes there's just nothing to suggest really :-)
<danvet>
but at least indicating which plane or crtc pushed stuff over the limit is useful
<agd5f>
Venemo, not sure. mareko or pepp may know
iive has joined #dri-devel
<Venemo>
I thought it was disabled due to some hard to reproduce GPU hangs a while ago
<pq>
danvet, these are not exactly more detailed error code, as in, they still would not help at all to figure out what something-else to try next.
mattrope has joined #dri-devel
<pq>
danvet, they just tell the difference between "world is burning" and "you're asking too much"
<pq>
which right now are pretty much indistuinguihsable (-typos)
<danvet>
well knowing which part of the world is burning should help?
<danvet>
instead of trying everything
<pq>
danvet, the idea is to answer the question "should I even bother trying something else"
<pq>
if the world is burning, it doesn't matter which part, there is nothing you can do
<pq>
granted, the difference is nuanced and it took me a while to maybe understand what emersion was looking for
Ahuj has quit [Ping timeout: 480 seconds]
<vsyrjala>
how do you define which is plane that is the too much when you try to enable N planes and just happen to exceed some global bandwidth limit?
<vsyrjala>
can't type today. oh well, maybe it can be parsed
<jekstrand>
hakzsam: Also, now that maintenance4 landed, it uses init. :)
<jekstrand>
hikiko: Ok. Good luck with that!
unsolo_ has quit [Ping timeout: 480 seconds]
<hikiko>
thank you :)
<hakzsam>
jekstrand: great, I started to work on vk_image_{view}_init() for RADV
<jekstrand>
👍
<dianders>
dri-devel list is unhappy. <dri-devel@lists.freedesktop.org>: Command died with status 1: ... IOError: [Errno 28] No space left on device
<jekstrand>
daniels ^^
<emersion>
yeah working on it
Duke`` has joined #dri-devel
nchery has joined #dri-devel
<cwabbott>
jekstrand: a vk_image_view that uses Vulkan formats might be a no-go for turnip
<cwabbott>
so, qualcomm has image compression like everyone else, and they also have hardware support for NV12 formats
<cwabbott>
well, guess what... the Y plane for some of these formats has a *different* compression from R8
<cwabbott>
so the first plane of an NV12 image is actually a different HW format that's I-can't-believe-its-not-R8
<cwabbott>
this means that either we do something gross like have our own internal VkFormat enum or we have our own format (probably pipe_format) permeate the driver
<cwabbott>
and one of the places that it needs to permeate is the blit/copy code, which leans on the image view code to create the descriptors/registers for copying, and it needs to create its own internal views for stuff
sdutt has quit []
sdutt has joined #dri-devel
pcercuei has quit [Quit: leaving]
<jekstrand>
cwabbott: Yeah, we have the same problem. :) And isl_format permeates the driver.
<cwabbott>
so, we propagate our own enum that can represent "Y8" everywhere, but then we run up against the fact that it needs to create its own internal views and those views need to take a pipe_format
<jekstrand>
cwabbott: isl_view. :)
<jekstrand>
cwabbott: Yeah, it's not a great situation, frankly.
<jekstrand>
And meta makes it really hard
<jekstrand>
I think it's easier for us because we don't meta
<cwabbott>
we don't really meta either
<cwabbott>
the only place we call into other parts of the driver is for image views (to construct the descriptor) and the compiler
hansg has quit [Read error: Connection reset by peer]
<jekstrand>
So, if you don't meta, why does your blit/copy code need an tu_image_view?
<pepp>
Venemo: I think some changes were made in the kernel. And SDMA usage in Mesa has been simplified a lot (no synchronization needed between gfx and sdma for instance)
<jekstrand>
Why not use ir3_view (or whatever you call it) directly?
<cwabbott>
jekstrand: because there is no ir3_view :)
<cwabbott>
err, fdl6_view I guess
<cwabbott>
so you have your own image view struct that doesn't derive from vk_image_view and then you just use that?
hansg has joined #dri-devel
<jekstrand>
Well, there's your problem. :P
mbrost has joined #dri-devel
<jekstrand>
cwabbott: Yup, isl_view
<jekstrand>
And, yes, that means there's duplication. Meh.
<cwabbott>
anholt: ^^^
<jekstrand>
It's worse than duplication, even. We have 3 isl_views and one vk_image_view for each anv_image_view
<jekstrand>
Because isl_view is per-plane
<cwabbott>
jekstrand: yeah, currently vulkan and gallium do all this descriptor programming separately
* jekstrand
really wishes TGSI caps were easier to grep for
jekstrand[m] has joined #dri-devel
<zmike>
amen
<zmike>
PIPE_CAP_TGSI_THREE_VERTEX_DRAW_SUPPORRT to be able to draw triangles
<zmike>
you can't even tell me you know whether that's real or not without checking
rgallaispou has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt: Does softpipe use nir_to_tgsi these days?
<anholt>
jekstrand: yep. there's a flag to go back to straight tgsi for comparison.
<jekstrand>
Ok. Mind if I slightly break TGSI?
<jekstrand>
And by slightly break, I mean delete the GLSL IR lowering for ldexp and frexp
<anholt>
having worked in tgsi: you think it's not horribly undefined and broken already?
<jekstrand>
I've not worked in TGSI. :P
<anholt>
jekstrand: svga looks like the only driver using TGSI_OPCODE_LDEXP.
<anholt>
if we could get them on ntt, we could GC a lot of stuff probably. but how do you test svga?
<jekstrand>
anholt: It dumps into "Unexpected TGSI opcode" :)
<jekstrand>
So it doesn't handle it. :)
<anholt>
fantastic!
<anholt>
+1 to deleting glsl ir code
<jekstrand>
Ok, first step is to garbage collect that.
<jekstrand>
anholt: It's also handled by tgsi_exec so, softpipe?
<jekstrand>
But I can turn on the lowering for softpipe
<anholt>
oh, virgl might be the other driver you have trouble with. they don't explicitly handle the opcodes because it's just shove tgsi over the wire
<jekstrand>
*sigh*
<anholt>
I've got a flag to do ntt for them, but it's not quite ready to become default
<anholt>
yeah, I think softpipe does do ldexp. I seem to remember having to debug it for ntt for softpipe.
<jekstrand>
Do we care? I think not.
<anholt>
jekstrand: last I tried, we were at 3 new failures (and 5 fixes) with virgl on ntt instead of direct tgsi. so it's pretty close, could probably push it over the line if you needed.
<anholt>
jekstrand: well, if you're doing some nir lowering instead of glsl, softpipe is fine.
<jekstrand>
Thing is, neither softpipe nor virgil set PIPE_SHADER_CAP_TGSI_LDEXP_SUPPORTED
<jekstrand>
So I think their handling of it is dead code
<anholt>
\o/
<jekstrand>
Ugh... no.
<jekstrand>
tgsi_exec.h has its own caps thing
<jekstrand>
which does claim support
<jekstrand>
But, also, do we care?
<anholt>
what change are you talking about doing, actually? I was guessing moving lowering from glsl to nir
<jekstrand>
Ultimately, I'm trying to get rid of the GLSL lowering
<jekstrand>
But the way it's controlled through gallium is weird
unsolo has joined #dri-devel
<anholt>
just use the existing shader cap to control the lowering, assert that it's not set when !prefers_nir?
<jekstrand>
We're currently always lowering FREXP for 32-bit but we don't for 64-bit if PIPE_SHADER_CAP_DFRACEXP_DLDEXP_SUPPORTED
<jekstrand>
So no one supports 32-bit frexp
<jekstrand>
Or if they do it's untested
<jekstrand>
radeonsi does. They have HW for it.
<jekstrand>
No one else does AFAICT
<jekstrand>
except softpipe and friends
<jekstrand>
But the radeon paths are only tested with RADV today
<jekstrand>
softpipe could be added, I guess.
<jekstrand>
So I have two options:
<jekstrand>
Well, three
<jekstrand>
1. Add a TGSI opcode for 32-bit FREXPP
<jekstrand>
2. Delete the TGSI support for 64-bit frexp
<jekstrand>
3. Keep everything weird
<jekstrand>
I don't like 3. That seems to be the option no one actually wants.
<anholt>
as far as 1), isn't that the existing TGSI_OPCODE_LDEXP?
<anholt>
sorry, you said frexpo
<jekstrand>
yeah
<jekstrand>
I'm starting to lean towards 2
<anholt>
honestly, I think these instructions are rare enough that just lowering seems great.
<jekstrand>
Yeah
<jekstrand>
probably
<jekstrand>
so option 1, then.
<anholt>
if all the HW drivers are lowering, then let's just let the layering or software drivers lower too.
<jekstrand>
Not all HW drivers are lowering
<jekstrand>
radeon has HW for it
<jekstrand>
They're the only one, though.
<jekstrand>
And it's super-easy in SW because LLVM and cstdlib have it
<anholt>
I think maybe I meant "!prefers_nir HW drivers"
<jekstrand>
THere are no !prefers_nir HW drivers that handle GL 4 or GL ES 3.1
<jekstrand>
They were introduced pretty late
<anholt>
given that, I'd vote to GC TGSI stuff.
<jekstrand>
Sounds like a plan.
<jekstrand>
If someone really cares about GL 4 features on softpipe, they can eat the perf
<anholt>
what sent you down this rabbit hole?
<jekstrand>
I noticed that every single Vulkan driver except RADV called nir_lower_frexpp
<anholt>
if we cared about softpipe, we'd be writing a nir-based interpreter.
<jekstrand>
fair
<anholt>
I think I succeeded at getting softpipe enough better than swrastc, I feel done with it.
<anholt>
though deleting tgsi_exec *would* bring me great joy
<jekstrand>
heh
<anholt>
but !8044's the real thing I want.
<jekstrand>
yeah
<jekstrand>
anholt: For that matter.... Can we get rid of 64-bit support from TGSI entirely?
<jekstrand>
I guess virgil might not be happy with that...
<anholt>
I can't remember the status of actual use of 64-bit virgl.
gouchi has joined #dri-devel
<anholt>
in chrome os they're doing GL4 in the linux container, but I'm not sure which side lowers 64-bit.
ngcortes has joined #dri-devel
<jekstrand>
If people are trying to do GL 4 with virgil, I'd rather they pass fp64 through
<anholt>
(if you have immediates as tex coords, it'll run out of space in a fixed-length buffer)
sneil_ has quit []
sneil has joined #dri-devel
Venemo_1 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<jekstrand>
:(
alyssa has left #dri-devel [#dri-devel]
<hikiko>
question: I've never used the Rebase button on gitlab, and I wonder what happens in case of a conflict, can you cancel it and do it manually?
<jekstrand>
If there's a conflict, the button will be greyed out
<jekstrand>
If there's a race that causes a conflict between when you push the button and the actual rebase, it'll give you an error message and not rebase.
<hikiko>
great then :) time to press it, thank you!
<Ristovski>
Hmm, just upgraded from an old-ish version of mesa to one with libglvnd enabled, and running anything on my dGPU hangs the GPU with "[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=2656, emitted seq=2657" any ideas how I can debug this? It manages to recover on its own but I have to kill the process
<Ristovski>
Hmm, it hangs right before printing OpenGL ES stuff in `glxinfo`
mbrost has quit [Ping timeout: 480 seconds]
hansg has quit [Remote host closed the connection]
elongbug has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
<jekstrand>
airlied: Yeah, some 64-bit int code. The exponent half isn't too horrible, honestly, because the exponent always fits in the top 32b.
<jekstrand>
The mantissa part is also not nearly as bad as you'd expect because, again, you mostly just smash on the exponent.
<jekstrand>
airlied: Looks like, all told, it should be < 10 instructions, even for 64-bit on a non-fp64 system.
<jekstrand>
non-int64, rather
<Ristovski>
Hmm, I'll try downgrading mesa and libdrm, smells like a libdrm bug though
<Ristovski>
I was right :P
<Ristovski>
sigh, well that's something to debug over the weekend >_>
<Ristovski>
Extremely lucky that the amdgpu gpu reset works
xexaxo has quit [Read error: Connection reset by peer]
Venemo_1 has quit []
xexaxo has joined #dri-devel
gawin has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Venemo has joined #dri-devel
<jekstrand>
zmike: Is zink genuinely broken or is my utterly trivial compiler patch causing GLX to stop working?