<jenatali>
I haven't tried to re-run a full CL run since upstreaming - we had planned to get a new hire to dig into that but he hasn't gotten there yet
<airlied>
jenatali: that looks to be in master actually just changed a bit over time
<jenatali>
Ah ok, I just searched 'fneg' in commit history
<airlied>
though I might have a similiar problem somewhere else
<jenatali>
I guess if you're not running lower_fneg, but doing the same logic inside llvmpipe, that could do it
<airlied>
jenatali: yeah seems to be it alright
<jenatali>
The only other change I had to make specifically for contractions was to tell the backend driver not to do math refactoring (i.e. don't ffma). Not needed for WARP which doesn't do that, but needed for hw
<zmike>
jenatali: have you had a chance to look at moving to mesa/st primconvert yet?
jernej_ has quit []
<jenatali>
zmike: Not yet, I saw the tag though
<jenatali>
If it looks like we're going to be the last holdout keeping you back, ping me and I can prioritize it
<zmike>
I'm gonna speculate that you are, but I also haven't looked at who I need to ping for the other remaining drivers
<jenatali>
Really? that was a long list of drivers
<zmike>
3 are off the list already
<zmike>
and I think you're going to have the most work to switch
* jenatali
sighs
<jenatali>
zmike: I can probably do that next week
<zmike>
cool
<zmike>
it's not like a huge priority but I don't want it to get dragged out to the point that it gets forgotten
<jenatali>
Yeah I hear you
<zmike>
mainly I think you're going to have issues with your edgeflag stuff
slattann has joined #dri-devel
<jenatali>
I honestly haven't looked at any of that code, so I have to learn it all before I can realistically change it :)
<zmike>
which has the other ticket for discussing that
<zmike>
it's a fun journey
<robclark>
jenatali: if it makes you feel better, between vacations and kernel/igt/product/etc things, I haven't had a chance to look at it either
<robclark>
sorry zmike
<zmike>
robclark: I suspect yours will be a trivial one like etnaviv and panfrost did
<robclark>
zmike: feel free to just try it and see what CI says (although freedreno farm will be offline for moving Sat)
<zmike>
uh...maybe
<robclark>
otherwise, if you have other things to do, no worries.. I'll get to it
<zmike>
will have to see how much time I spend tomorrow doing cts runs
<robclark>
but part of what the CI farm is there for is to let people test things on hw they don't have in front of them ;-)
<zmike>
thus far my experience with that has been does this work -> no -> end up bugging someone anyway
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<zmike>
robclark: does fd handle edgeflags?
<imirkin_>
(it does not)
<zmike>
then probably it should be trivial
<jenatali>
zmike: You said I'd have issues with edgeflag stuff - got a pointer to it?
<jenatali>
I'm not quickly finding it
<zmike>
uhhh
<zmike>
if you search for primconvert in mesa issues
<zmike>
I made 2 tickets
<zmike>
tl;dr edgeflags are gonna be broken for anything that gets primconverted because the edgeflags don't also get primconverted
<imirkin_>
additionally, chances are anything which *needs* primconvert won't support edge flags to begin with...
<robclark>
zmike: no edgeflags.. I guess it isn't a gles thing, which is kinda where our focus has been from a shipping-things PoV
<zmike>
robclark: that's what I figured
<jenatali>
zmike: Oh as long as it doesn't make us worse than we currently are, cool
<zmike>
jenatali: you're handling them in your driver now which lets you avoid that, but there's nothing to do that in vbuf/primconvert, which is the last place that sees the unconverted draw
<jenatali>
Uh... we are?
<zmike>
I'm pretty sure I saw edgeflag stuff there when I was grepping
<jenatali>
D3D hasn't had edgeflags since 9
<zmike>
yeah so you're probably converting to clipdistance or something
<jenatali>
So I dunno what we'd be doing with it
<imirkin_>
GL dropped them in core
<imirkin_>
but they're still around in compat
<imirkin_>
i.... don't see how edge flags might be connected to clip distance.
jernej_ has joined #dri-devel
<jenatali>
Same
<jenatali>
zmike: I don't see any hits for "edgeflag" in d3d12
<zmike>
edge_flag?
<jenatali>
Ooh, there it is
<imirkin_>
edge flags are basically indicators of whether a particular line should be drawn when glPolygonMode(GL_LINES)
<imirkin_>
so you're drawing a bunch of triangles, all things being equal you'd get the full mesh-looking thing
<imirkin_>
but with edge flags you can indicate that certain lines aren't to be drawn
<zmike>
yep
<imirkin_>
in GL 1.0 you enable/disable it, with GL 2.0 you can actually feed it in as a special vertex attribute
<imirkin_>
NVIDIA hardware only supports the GL 1.0 way of doing it though. but ATI/AMD and i believe Intel hw all support the GL 2.0 way
<imirkin_>
(i.e. on nv, you just flip the flag, feed some vertices, flip the flag again, feed some vertices, etc. highly efficient...)
aravind has joined #dri-devel
buhman has quit [Ping timeout: 480 seconds]
<jenatali>
I see, looks like we turn it into a linelist and then use a GS to filter out lines
<imirkin_>
that sounds effective.
<jenatali>
Sounds like primconvert should handle that?
<jenatali>
Or rather, shouldn't break it
<zmike>
hmmm
<zmike>
you're injecting a gs though
<imirkin_>
jenatali: and if there's already a GS?
<imirkin_>
good times are had by all?
<jenatali>
imirkin_: Does 3.3 have API GS?
<mareko>
GL 2.0 edgeflags are a fixed-func feature even with shaders enabled, it's only Mesa that converts them to a vertex shader output
<imirkin_>
jenatali: sure
<jenatali>
Then I have no idea :)
<imirkin_>
GS is GL 3.2+
<imirkin_>
jenatali: one solution is to not expose compat GL 3.2+ contexts :)
jernej_ has quit [Ping timeout: 480 seconds]
<zmike>
primconvert has no awareness of existing shader states, so that's a bit tricky
<jenatali>
imirkin_: Oh hey that's our solution!
<imirkin_>
it's a good one!
<jenatali>
Yeah except I really do want to support that at some point
<mareko>
I think tess and GS ignore edge flags
<zmike>
jenatali: probably just post up on the primconvert improvements ticket for discussion
<imirkin_>
mareko: ah yeah, that sounds right
<imirkin_>
i think on nvidia, if you have tess/gs, then any edge flags you feed in are thrown out the window
buhman has joined #dri-devel
<imirkin_>
jenatali: the GS which skips lines seems like a very good idea ... and especially doable since mesa already feeds the edge flag in as a vertex attrib
<jenatali>
imirkin_: Wish I could take credit :P
<zmike>
I think for existing gs we could just have a pass that drivers can call when edgeflags are present
<imirkin_>
zmike: i think with existing gs, you just skip edge flags
<imirkin_>
(and tess)
<zmike>
is there an actual case of it?
<imirkin_>
it can't work even if there were
<zmike>
then we're all set
<imirkin_>
so edge flags are only a thing when there's only a VS
<mareko>
I think GS can't handle edge flags for quads and polygons
<mareko>
or can't lower
<imirkin_>
those would have to be converted to trifan's first :)
<imirkin_>
(with the appropriate edge flags thrown in for good measure)
<jenatali>
Just writing out an index buffer from an already primconverted vertex buffer
camus has quit [Ping timeout: 480 seconds]
jernej has joined #dri-devel
<jenatali>
Anyway, not sure when I'll be able to get time to dig in closer, I'd really love to not have to take a regression to switch over though
jessica_24 has quit [Quit: Connection closed for inactivity]
Company has quit [Quit: Leaving]
<zmike>
just move that gs over to primconvert; if edgeflags are active then there can't be a gs, so you can just generate and temporarily bind that gs during the converted draw
<imirkin_>
wellll ... if edgeflags are active AND there is a GS, then you can ignore the edge flags. additionally you have to be a bit careful to only do this when glPolygonMode(GL_LINES).
<imirkin_>
although ... what do you do when glPolygonMode(GL_FRONT, GL_FILL); glPolygonMode(GL_BACK, GL_LINE);
<imirkin_>
jenatali: --^
<imirkin_>
i assume d3d9 has separately-settable polygon modes?
<zmike>
I have some patches to pass through edgeflag presence to primconvert, could prob do the same for gs
<jenatali>
imirkin_: not sure about the API, at the driver level it's just triangle fans plus edge flags
<imirkin_>
jenatali: right, but ... this happens when you set the polygon mode to GL_LINES
<jenatali>
Oh, front vs back, no that's never been a thing in d3d
<imirkin_>
but it coudl be that only some of the tri's need this treatment
camus has joined #dri-devel
<imirkin_>
jenatali: what's the API call to set the polygon mode in the first place, if you know?
<imirkin_>
with GL, i no longer thing this is doable with different front/back fill modes
<jenatali>
Yeah. What a weird feature to be able to do separate front/back modes
<imirkin_>
:)
<imirkin_>
welcome to the jungle
<jenatali>
Yeah...
<jenatali>
Anyway I'm done for the night
<imirkin_>
gitlab appears to be with you
slattann has quit [Read error: Connection reset by peer]
<anholt_>
jekstrand: yeah, stacking another irqchip on your irq is probably a reasonable idea. though it means having to interact with another linux subsystem maintainer in order to get patches in so I would avoid it unless it's a big win.
danvet has joined #dri-devel
slattann has joined #dri-devel
<zmike>
when the servers get fixed, can someone marge !12586 for me? thanks!
idr has quit [Quit: Leaving]
sagar_ has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
sagar_ has joined #dri-devel
Duke`` has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mlankhorst has joined #dri-devel
slattann has quit []
thellstrom has quit [Remote host closed the connection]
JohnnyonF has quit [Read error: Connection reset by peer]
boistordu_ex has quit [Remote host closed the connection]
shfil has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
xexaxo_ has joined #dri-devel
boistordu_ex has joined #dri-devel
shfil has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
slattann has quit []
Peste_Bubonica has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
thellstrom has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom1 has quit []
thellstrom has quit [Ping timeout: 480 seconds]
flto_ has quit []
flto has joined #dri-devel
nirmoy has joined #dri-devel
hansg has joined #dri-devel
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
aravind has quit []
APic has joined #dri-devel
<APic>
Hi
<zmike>
gitlab down again?
<APic>
I got some Graphic-Glitches (horizontal Bars) in some X-Applications, for Example VirtualBox, Firefox and Wine (‑ but not urxvt, Chrome, Pidgin), after upgrading the Packages libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 from 20.3.5-1 to 21.2.1-1 in Devuan ceres
<APic>
These Artifacts only appear in OpenBox and Fluxbox, but not in WMs with Compositing like Gnome and Plasma (KDE)
<zmike>
daniels: gitlab is sad again help
<APic>
Now i would like to manually compile the latest GIT-Version of Mesa and see if that fixes the Problem
<APic>
And if not report the Issue
<APic>
My Graphic-Chip is: 00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 05)
<APic>
Are the Sources of all of the Packages libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 in there?
<APic>
Uh huh, probably this GITLab is down for me also -_-
<APic>
HTTP 502 curl 22 The requested URL returned error: 502
xexaxo_ has joined #dri-devel
vivijim has joined #dri-devel
dviola has joined #dri-devel
bcarvalho has joined #dri-devel
<daniels>
zmike: it repaired itself before I could repair it
<daniels>
APic: it's back
<zmike>
:/
<APic>
o/
<zmike>
it's been doing this a lot over the past day
<daniels>
I've noticed
<daniels>
I suspect there is something deeply weird with our network fabric
<daniels>
since what's killing it ... isn't actually true
sdutt has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
<APic>
Though „git clone git://gitlab.freedesktop.org/mesa/mesa.git“ still does not work, or at least takes very long, but that is probably intended? 😉
Peste_Bubonica has quit [Quit: Leaving]
<imirkin>
i think you want https://
<jekstrand>
git:// should work if you've got the right URL
<jekstrand>
But, yeah, for a RO clone, https:// is fine
<imirkin>
and for RW, you use ssh
<imirkin>
not sure when you use git...
<jekstrand>
These days, I don't
<jekstrand>
Especially if you ever have to deal with proxies. They all know about https and ssh, but git tends to be blocked.
<emersion>
danvet: i'm having issues improving amdgpu's checks for the cursor plane, because hw is weird and chromeos uses the legacy cursor API with the atomic API
<emersion>
i'm wondering, would it make sense to have a CLIENT_CAP_NO_LEGACY to completely disable all of the legacy APIs?
<emersion>
and allow the driver to make sure all state changes go through the atomic API
<emersion>
thus allowing to remove some plane restrictions
<emersion>
the gist of the amdgpu issues is: i'd like to check some things when enabling the cursor plane, but i can't because the legacy API assumes the cursor plane always works
<zmike>
daniels: dead again
cphealy has joined #dri-devel
gouchi has joined #dri-devel
camus1 has quit []
<danvet>
emersion, uh, what kind of checks are those?
<danvet>
also "legacy cursor always works" isn't quite true, you can fail
<danvet>
which should trigger a fallback to sw cursor until next modeset maybe
<danvet>
there's been some i915 gen8 where the cursor does fail for random reasons
<danvet>
but only on the 3rd crtc, so perhaps not seen much in the wild
<zmike>
ooh pubkey denied now from gitlab
<zmike>
I think I made it angry
<imirkin>
zmike: nah, it was me. i pressed a button.
<imirkin>
that defeated it.
dviola has quit [Ping timeout: 480 seconds]
<imirkin>
gitlab _really_ doesn't want me to test stuff on a530 :)
<jekstrand>
Is gitlab being problematic for anyone else?
<imirkin>
jekstrand: it hasn't worked since last night for me
<tomeu>
@daniels anything changed in the past few hours in gitlab that keys are being refused?
<zmike>
yeah it started being flaky last night
<jekstrand>
Bah
<zmike>
the key rejected thing is new though
<jekstrand>
Ok. I guess my morning of code review will have to get cut off early
<imirkin>
when i first tried to test the multisample enable/disable flag on a5xx. i assume that's what did it in.
<tomeu>
I have at least been able to push things during my day, but not any more
<daniels>
no it's just fucked
<daniels>
nothing has been changed or upgrade, it's just broken
shfil has quit [Quit: Konversation terminated!]
<daniels>
I mean why would you even need internal DNS to work anyway
<imirkin>
should just be using IP addresses.
<imirkin>
that'll teach ya!
<imirkin>
(preferably MAC addresses so you don't have to deal with ARP...)
<kallisti5>
is git down?
<kallisti5>
remote: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp: lookup gitlab-prod-gitaly-0.gitlab-prod-gitaly.gitlab.svc on 10.41.0.10:53: no such host"
<daniels>
YES
<kallisti5>
oh.. sorry. Didn't read up. Carry on :-)
nchery has joined #dri-devel
<jenatali>
Seems like something that should be posted on the GitLab page... oh wait
<imirkin>
like "The email system is down" emails, or the bios saying "Keyboard error, press F1 to resume"
<kallisti5>
jenatali: err. I don't see it on the gitlab page
<kallisti5>
anyway.. it's fine. good luck :-)
<jenatali>
It was a joke. If GitLab is down, you can't inform people that it's down using it
<kallisti5>
ah ok. thought I was missing something :-D
<kallisti5>
also.. gitlab the webui is up
<daniels>
jenatali: i mean you can set up nginx to bounce 5xx to a static status page
<daniels>
preferably one directing people to ask in here about it
<kallisti5>
daniels: I manage a lot of kubernetes clusters professionally... let me know if you need any help
<kallisti5>
that error looks like the kubernetes service for a pod is down or the pod isn't starting
<daniels>
kallisti5: one of the nodes went down for unknown reasons and that's made ceph very unhappy - quite why that caused DNS to fail is beyond me, but let's see when it comes back and the storage becomes coherent again
<emersion>
danvet: the cursor scaling and rotation must match the overlay plane if any, or the primary plane otherwise
<Venemo>
rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp: lookup gitlab-prod-gitaly-0.gitlab-prod-gitaly.gitlab.svc on 10.41.0.10:53: no such host"
<kallisti5>
Venemo: known issue
<Venemo>
:(
<danvet>
emersion, why would this break cros?
<kallisti5>
daniels: I can at least respond to people bringing it up to help out :-)
<emersion>
danvet: typical issue is chromeos disables cursor plane, enables overlay, then tries to enable cursor and fails
<emersion>
or the reverse: chromeos enables primary+overlay+cursor, then disables overlay and fails
<emersion>
(because primary is scaled)
<danvet>
yeah, but if the hw can't do it, then lying about that cursor doesn't sound like a bright idea either
<daniels>
there you go, it's back
<kallisti5>
daniels: nice!
<emersion>
danvet: hm what do you mean?
<kallisti5>
daniels: working here
<danvet>
emersion, well if we don't have this check, the cursor uapi is also broken
<robclark>
danvet: cros compositor has.. issues.. doing atomic-test properly :-(
<danvet>
since if you play a really low-res video with the overlay, it'll look very funny I guess
<danvet>
robclark, well it's not easy ...
<emersion>
danvet: right now, because of cros, the overlay cannot be enabled in amdgpu, just in case the cursor might be enabled via the legacy uapi
<danvet>
uh
<emersion>
might be enabled later*
<danvet>
that sounds bad tbh
<danvet>
imo we should enable it
<danvet>
and then have a "I_am_cros_compositor" switch with the old restrictions
<emersion>
siqueira: ^
<danvet>
and cros maybe should get their atomic fixed
<emersion>
cc seanpaul
<danvet>
I mean amdgpu is also rather more like classic display overlays from like 20 years ago and not so much modern unified planes, but that's kinda no good reason to just disable it outright
<emersion>
yeah, amdgpu's cursor is a lie
<danvet>
essentially the cros knob woould a) disable all overlay planes b) disable all scaling
<danvet>
maybe we can get away with only one of them, dunno
<emersion>
i think cros is mainly interested in… disabling scaling on the overlay plane
<emersion>
cros actively uses the overlay plane
<danvet>
yeah if we can get away with it by just disabling scaling, then that should do the trick
<danvet>
maybe make it a Kconfig too
<danvet>
default y
<emersion>
it uses the primary plane to scale a video, and the overlay to draw controls
<danvet>
and check with airlied whether that's ok or too much uapi bending or not enough
<danvet>
assuming siqueira and hwentlan are ok ofc
<emersion>
alright, thanks for the feedback
<emersion>
i'll try to sum all of that up onb dri-devel
<danvet>
well Kconfig should just set the default I guess, plus maybe call it something else to not punch cros compositor too much here
<robclark>
emersion: we've had similar issues with cros compositor on msm.. solved with downstream hack patch.. we don't need upstream patch for this
<zmike>
robclark: I got the fd patches done, gonna try to test when I get a chance later
<robclark>
zmike: ok.. heads up that fd farm is going to be offline tomorrow to move to new office
<zmike>
uh oh
<zmike>
well I'm sure I'll get it on the first try with no issues
jessica_24 has joined #dri-devel
<robclark>
heheh
sdutt has quit []
sdutt has joined #dri-devel
<Venemo>
who is responsible for freedreno these days?
<robclark>
I suppose I am
<Venemo>
we have a NIR optimization that has been blocked by freedreno CI for 9 months due to a bug in freedreno's backend
<robclark>
Venemo: if it is just traces changes.. you can update hashes if the result image looks ok.. some of the things (in particular glmark2) are really sloppy about precision
<Venemo>
the result image looks like garbage
<robclark>
which one?
<Venemo>
the one because of which the CI fails it?
<Venemo>
perhaps pendingchaos has more information
jhli has quit [Read error: Connection reset by peer]
<Venemo>
robclark: sorry for barging on you with this like that, but we have some further work that depends on that optimization, and I thought it may be time to check in and ask what's up with it
<robclark>
no worries.. if you hadn't mentioned it I wouldn't have noticed
<Venemo>
oh
<Venemo>
I thought one of us had already alerted you to this some months ago
<robclark>
I'm covering kernel and mesa and also product issues at the same time.. so easy enough for me to miss things
<Venemo>
would appreciate if you could look into this please
<robclark>
yeah, I'll take a look
<pendingchaos>
"volplosion" is the trace
<pendingchaos>
other drivers look fine, but freedreno looks incorrect
<robclark>
I suppose if 3mo ago was last time you tried, it could be worth trying again.. cwabbott has been doing a lot of work on RA so a fair bit of compiler has changed since then
<zmike>
can someone Marge !12582? network failed
<zmike>
gitlab keeps expiring my mobile cookies
<Venemo>
zmike: marged
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<pendingchaos>
I think I tried again when I rebased about a week ago, though gitlab isn't showing it for some reason
<zmike>
thx
<daniels>
zmike: yeah your sessions got dropped in all the flapping
<zmike>
toxic
<daniels>
it was necessary for community health
<robclark>
pendingchaos: it doesn't look *completely* wrong, I guess mad vs fma precision issue (but AFAIU those differences are within what gl allows)
<pendingchaos>
robclark: IIRC, for me, it looked much less smooth and had discontinuities
jhli has joined #dri-devel
<robclark>
that ofc could still be a precision issue
<robclark>
yeah, that is what I'm seeing locally..
<robclark>
standard test of adding lots of extra nop's and sync flags doesn't change anything, so not a scheduler or legalize issue (but otoh those issues would show up all over the place if that was the problem).. changing nir ffma to map to mul.f plus add.f doesn't change anything..
sylware has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
<robclark>
pendingchaos: I'll try to look more over the weekend, but I guess that it is "fine" (ie. shader expects more precision somewhere than glsl guarantees and the error gets amplified, or something along those lines)
<dcbaker>
airlied, kusma, @idr: I've applied "nir/lower_bit_size: Support add_sat and sub_sat" to 21.2, and it's causing a constant regression to lavapipe. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/13147423, I can't find anything in main that seems like it would fix this, do you have any ideas?
<dcbaker>
or if you have ideas who might know better :) I'm not really sure who "owns" lavapipe
<kusma>
Uuuh, that one seems like it might really be some other change, just ci didn't trigger or something
<alyssa>
Is it acceptable for a DRM driver to also expose a backlight device (with devm_backlight_device_register), keeping the code in drivers/gpu/drm instead of video/backlight?
<alyssa>
(If not I'll need to be very careful about how to structure this copro thing..)
<alyssa>
(If yes, the whole driver goes in drivers/gpu/drm. If no, the copro pieces go in drivers/soc/apple and then two shim drivers get added in gpu/drm and video/backlight, and there would probably be global variable shenanigans.
<alyssa>
)
<daniels>
alyssa: i915 is prior art for yes
* emersion
still hopes for a backlight KMS prop…
<alyssa>
daniels: 👍
<alyssa>
Granted the mac mini doesn't even have a backlight to worry about so as long as I don't give in and buy a macbook, I don't have to think about that 😉
<HdkR>
An M1X/M2 macbook won't be able to be resisted though :)
<daniels>
zmike: going to disable your account as it’s clearly been hacked
<zmike>
fffffffffuuuuuuuuuuuuuuuuuuuuuuuuu
<HdkR>
Too many PRs, clearly hacked
<robclark>
daniels, tomeu, MrCooper, (or in general anyone who knows gitlab yml rules stuff), opinions about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12602 ? Still WIP since at least the 2nd patch I don't intend to merge until tomorrow morning. But seems to be doing what I intended.
<daniels>
robclark: yeah A-b
<alyssa>
daniels: oh, that was me,i'm a mesa addict, didn't want people to know i was fixing tests on vacation so I used zmike's account 🙃
sneil has quit [Quit: Leaving]
<robclark>
daniels: thx
sneil has joined #dri-devel
JohnnyonFlame has joined #dri-devel
macromorgan is now known as Guest5582
gouchi has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
Guest5582 has quit [Read error: Connection reset by peer]
nsneck has joined #dri-devel
<daniels>
alyssa: selfless!
Ahuj has joined #dri-devel
<alyssa>
🙃
ngcortes has quit [Ping timeout: 480 seconds]
nirmoy has quit []
<APic>
Ok, with a manually compiled mesa 21.3.0-devel i get the same Glitches as with 21.2.1-1
<APic>
Time to git-bisect 20.3.5 and 21.2.1 i guess
* APic
never used git-bisect before, so i am eager to learn something ☺
NiksDev has quit [Ping timeout: 480 seconds]
<mareko>
I bet zmike has an army of coding minions he's hiding from us :)
hansg has quit [Quit: Leaving]
<zmike>
if only
bcarvalho_ has joined #dri-devel
bcarvalho has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
<sravn>
alyssa: there are a few places where we have backlight in the display driver, and many panles include a backlight driver.
<imirkin>
nouveau also creates a nv_backlight thing
xexaxo_ has joined #dri-devel
<alyssa>
mareko: where do I get some of those to do CTS runs
<imirkin>
sometimes the backlight is attached directly to the gpu. other times not. leads to much confusion.
<sravn>
alyssa: so I would say that you go for the most simple solution, and from what you wrote that is not video/backlight/
<imirkin>
and there's some kind of further complication with oled displays which don't actually have a brightness at all
<alyssa>
sravn: absolutely, simplest is to keep everything in drivers/gpu/drm/apple
<alyssa>
and have that do both DRM/KMS and also backlight
<alyssa>
of course as far as simple solutions go I maybe have bigger issues. this line of code hurts me deeply:
<alyssa>
") = {" this bothers my mental C syntax checker
<imirkin>
no the fact that you have an array of generic callback functions which take void pointers?
<alyssa>
that too.
<alyssa>
Apple implements this in a pile of C++ using reflection or metaprogramming .. As far as ways to express in kenrel C this seems like a lesser evil
<alyssa>
(I assume generating trampolines in Python is a big no-no for upstream kerenl)
* alyssa
cannot spell krenel
<Sachiel>
clearly
<APic>
Okay, i finished Bisecting
<APic>
f62724ccacffb2a1508647e9004adf02f92f7833 is the first bad commit
<ccr>
Xinu L. must be some kind of scientology connection there.
<APic>
airlied: Does that fix the Glitch-Bug introduced by f62724ccacffb2a1508647e9004adf02f92f7833?
<APic>
Got to go to Bed now, will play around with it some moar tomorrow ☺
<APic>
cya and thanks
gouchi has joined #dri-devel
<robclark>
alyssa: you aren't writing the driver in rust?
* robclark
runs
<alyssa>
robclark: rust would swap out this problem for a different set 😉
<zmike>
sounds like you're probably not leveraging the full power of the language in that case
<robclark>
:-P
<dcbaker>
All problems in Rust can be solved by downlading 37 random crates from the internet
* dcbaker
runs
<zmike>
I didn't realize it was cardio time in here
<zmike>
everyone running all the time now
gouchi has quit [Quit: Quitte]
<FLHerne>
That beats JS, where you need 370
<dcbaker>
JavaScript: Taking bad ideas to the extreme since 1995™
<imirkin>
i've just spent the past week fighting "builds" of js ... not a fun time.
<dcbaker>
I've done a lot of Python and Ruby, but I find JavaScript development to just be awful. There's roughly a million ways to do anything, and all of them are completely and totally broken
<hch12907>
FLHerne: I think I have seen node_modules with more than 370 subdirectories before...
<danvet>
alyssa, there's plenty of .py in the kernel, and I think we have some ways to generate code too
<imirkin>
dcbaker: it's pretty horrid. it's additionally horrid that all these tools are also built in js.
<alyssa>
danvet: still sounds questionable. and I'm not yet convinced the net result is much better. We'll see
<alyssa>
not all problems can be solved by preprocessing harder
<alyssa>
but this one probably can
<alyssa>
idk
<alyssa>
Presumably there'd be a jump table in there regardless, just a matter of whether that's hidden from the rest of the driver
<robclark>
danvet: oh, you mean I won't have villagers coming after me w/ pitchforks if I pull the xml -> header generation we use in mesa into kernel build? That would be nicer than checking in generated headers
<alyssa>
robclark: hehehehe
<alyssa>
robclark: feel free to be prior art :-p
<danvet>
robclark, tbh I think that's the right way to do it, so happy to give it a shot
<alyssa>
(I do worry that metaprogramming can be a double edged sword... if you have a problem and solve it with metaprogramming you now have two problems..)
<danvet>
I'm not sure about adding xml dependencies to the kbuild though, that might be a harder sell
<robclark>
alyssa: yeah, but one of them is only a meta-problem
<airlied>
I think the in-tree py though isn't in the build process for the kernel itself
<alyssa>
but if you're already using header generation, 100% would rather have the original source form than the generated stuff
<airlied>
I think it's useful things for perf
<alyssa>
bonus points if you can shrink the disk size of the AMD registers while you're at it :-p
<airlied>
oh and sphinx
<robclark>
yeah, I kinda don't want to be the first person to try to add mandatory py dependency for normal kernel build.. it sounds like lots of flame emails in my inbox
<alyssa>
danvet: if I went the python route for DCP, the IPC definitions would be pure Python, no XML in there
<alyssa>
so might be an easier sell than envytools
<alyssa>
but I also would like to avoid flame emails in my inbox and the comments section focusing on why $INSERT_PROTECTED_CLASS_IM_IN sucks
<alyssa>
(there's enough of that when I do things that are *popular*, let alone controversial ...)
<danvet>
airlied, hm yeah I think python isn't in core kbuild :-/
<emersion>
maybe it would be possible to commit both the source XML, the python script and the generated headers in the tree?
<robclark>
I'd rather make it impossible to just add additional register definitions to the generated headers and then later have to work backwards to update the xml ;-)
<alyssa>
robclark: is code aurora doing that?
<robclark>
it happens every now and then.. not only qcom.. sometimes people don't know better or forget to send the xml patch.. having the primary src in mesa does complicate things for some folks at qcom
<robclark>
(so we have this whole mirroring into envytools tree thing)
<alyssa>
nod
<alyssa>
the set of structures needed in kernel vs mesa for mali is totally disjoint so that makes it easy for Arm i guess
<robclark>
we have some overlap.. what is *actually* needed in kernel is a pretty small subset.. but splitting it up would be extra work for me
<alyssa>
I am admittedly curious how you manage to have so many regs
<robclark>
a lot of those are enums
<alyssa>
I am admittedly curious how you manage to have so many enums
<robclark>
gpu support a lot of formats
<robclark>
these days adreno uses same format enum for all the things, which is kinda nice
<robclark>
(rather than separte for tex/image/fb/vbo/etc)
kvrmurthy has joined #dri-devel
<alyssa>
mali has done so since at least t6xx which is lovely
<alyssa>
apple does not of course.
<alyssa>
...oh, this is going to upset lockdep isn't it..
<alyssa>
danvet: wasn't me
<alyssa>
er maybe it's ok... wait, no, wait what apple how does your design possibly work..
<imirkin>
nvidia has separate enums too
rpigott has left #dri-devel [#dri-devel]
<imirkin>
RB enums are typed while texture ones aren't, so that's a pretty major difference
<mareko>
imirkin: the idea is that the definitions that are in the kernel can be used in open source, and those that are not can't be open source
<imirkin>
mareko: yeah, but instead of having perfctr0..173 you could declare it as an array
kvrmurthy has quit [Quit: Leaving]
kvrmurthy has joined #dri-devel
<imirkin>
(having fewer registers was a joke...)
<mareko>
it's all generated from something else
kvrmurthy has quit [Remote host closed the connection]
<imirkin>
also to merge multi-generation stuff
<imirkin>
rnndb does a pretty good job of allowing you to manage these things with minimal duplication
<mareko>
is that a joke too? ;)
<imirkin>
nope, that one was serious.
danvet has quit [Ping timeout: 480 seconds]
<robclark>
I assume amd follows the same "lets just move all the regs around between gens" approach that qcom does
<robclark>
(or really regs+bitfields)
<Venemo>
mareko: speaking of edge flags, can we simply always write 0 for edge flags in Vulkan? Or do we need to keep using the initial edgeflags like we do now?
<imirkin>
presumably always write 1?
<alyssa>
Ummmm async in the kernel seems "fun"
<Venemo>
Why 1?
<imirkin>
you always want the edge
<imirkin>
or is fill mode = line not a thing in vk?
vivijim has quit [Ping timeout: 480 seconds]
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
i-garrison has quit []
pcercuei has quit [Quit: dodo]
sdutt has quit []
sdutt has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
gpoo has quit [Remote host closed the connection]
pnowack has quit [Quit: pnowack]
tursulin has quit [Remote host closed the connection]