ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<tarceri>
jekstrand: its the same answer as your previous question, loop analysis doesn't record loop terminators that look like that and exists. loop unroll never has to worry about encountering such complex code
<tarceri>
nir_is_trivial_loop_if()
oneforall2 has quit [Remote host closed the connection]
<tarceri>
*exits
nchery is now known as Guest434
nchery has joined #dri-devel
stuart has quit []
<karolherbst>
ohh no.. I found the reason rusticl didn't work on nouveau
<karolherbst>
and I might just yolo API mappings, because the API is just so garbage
<airlied>
heat: I don't zink will overtake radeonsi, but I don't think writing a new gallium driver for vulkan capable hw is a decent place to spend time unless you have a real need
<karolherbst>
jekstrand: I hope you noticed that marge bounced your MR :P
<karolherbst>
ohh you fixed it
<karolherbst>
stupid mail client threading
<heat>
airlied, why wouldn't zink overtake radeonsi? is it impossible to reach roughly the same perf as a native gallium driver?
<heat>
or at least a performance delta small enough that reducing technical debt by deleting radeonsi would be worth it
devilhorns has quit [Remote host closed the connection]
mclasen has joined #dri-devel
<karolherbst>
"nvc0_program_translate:670 - shader translation failed: -2" I am quite happy that most of the fails with nouveau and rusticl are random things like this
devilhorns has joined #dri-devel
CounterPillow has quit [Quit: Bye.]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
CounterPillow has joined #dri-devel
CounterPillow has quit []
CounterPillow has joined #dri-devel
CounterPillow has quit []
halfline[m] has joined #dri-devel
Guest487 has quit []
CounterPillow has joined #dri-devel
imre has joined #dri-devel
CounterPillow has quit []
bmodem has quit []
CounterPillow has joined #dri-devel
<krh>
oh no, not -2
<pq>
krh, do you remember why Wayland c&p/d&d protocol has one of the clients creating the data fd instead of the compositor creating a pipe and passing the ends of that to each client?
<daniels>
pq: because if you're copying a JPEG you loaded from disk, you can just pass the FD to that
<pq>
daniels, except, it's the receiver creating the fd, not the sender.
<daniels>
good point
<pq>
krh, I pinged you in the gitlab issue in case you remember anything.
rkanwal has joined #dri-devel
MajorBiscuit has joined #dri-devel
<krh>
pq: I believe it was so that you don't have to round-trip to get the fd
<krh>
if a client wants the data, it sends a reqeust for it along with the fd to write it to
<pq>
ah, that simple reason
gdevi has joined #dri-devel
<daniels>
I definitely remember there being an efficiency argument too in avoiding copies if you can better control the allocation
OftenTimeConsuming has quit [Write error: connection closed]
OftenTimeConsuming has joined #dri-devel
hasebastian[m] has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
cheako has quit [Quit: Connection closed for inactivity]
bmodem has joined #dri-devel
alistairp has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
Guest454 is now known as bluepenquin
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
Company has joined #dri-devel
<jfalempe>
Hi tzimmermann, I'm preparing to push the mgag200 damage patchset with dim
<tzimmermann>
ok
<jfalempe>
the branch to use is drm-misc-next ?
<tzimmermann>
yes
<tzimmermann>
it's always open for new features. if you have a bugfix, it get's more complicated
<jfalempe>
btw, I just noticed a typo on the commit title of your patch 1/7 "drm:/mgag200: Acquire I/O lock while reading EDID" => should be "drm/mgag200:"
bmodem has quit [Ping timeout: 480 seconds]
<jfalempe>
to be like the other patches
<tzimmermann>
oh
<jfalempe>
I think I put only mgag200: in mine, should I start them with drm/mgag200: ?
<tzimmermann>
i'll fix that before merging
<jfalempe>
that would make history more consistent
<tzimmermann>
please do
<jfalempe>
ok
mclasen has quit [Ping timeout: 480 seconds]
<tzimmermann>
it also helps wrt other subsystems
<tzimmermann>
jfalempe, do you have other plans for the driver?
<jfalempe>
No, I don't have anything more than damage and gamma.
<tzimmermann>
ah, ok. no problem
<jfalempe>
feel free to rewrite it in rust ;)
<tzimmermann>
lol
<tzimmermann>
that's not gonna happen, but i want to restructure the source code, so that all the branching on mdev->type goes away
<tzimmermann>
i have a prototype for that
<tzimmermann>
but i first want to merge the fixes patches and wait for possible fallout
<jfalempe>
I saw in git history that you've already done a lot of refactoring, that was a pleasure to work with this version.
<tzimmermann>
indeed. the original version was taken from x11 and adopted to the kernel. tha didn't look well
mclasen has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
jagan_ has joined #dri-devel
kts has joined #dri-devel
pjakobsson has joined #dri-devel
iive has joined #dri-devel
enick_254 has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
<tomeu>
danvet: airlied: robclark: sorry, have been afk until a short while ago
<tomeu>
I see you have reached agreement, and I'm fine with it as well
<tomeu>
so I'm going to:
<tomeu>
1. move the ci/ subdir to drivers/gpu/drm/
<tomeu>
2. Have a SHA for drm-ci in there
<tomeu>
4. Add a gfx-ci/lab-status repo so we can skip jobs on labs that may be down at a given point without having to change the drm-ci SHA in the kernel repo
<tomeu>
3. Add rules to jobs so only a subset of jobs are run based on what files are changed
<tomeu>
0. Catch up with the thread in LKML
kts has quit [Ping timeout: 480 seconds]
<danvet>
tomeu, I think from linus on lmkl there was the question whether we could compress the results file a bit
<danvet>
by only listening failing stuff, not everything
<robclark>
tomeu: probably #3 is optional at this point, I don't think capacity is much of an issue at this point
<tomeu>
yeah, we should have only fails in there, but I was waiting to have a better runner for that (anholt's deqp-runner)
<danvet>
robclark, I guess #3 makes sense for hw labs
<danvet>
but as long as they can keep up it's ofc not needed
<robclark>
deqp-runner support for igt would be useful as a way to not list all the passing tests
<robclark>
yeah, when we get to point where #3 is needed, it is a good problem to have
<tomeu>
ok, can give that lower priority, but shouldn't be much work
kts has joined #dri-devel
ishitatsuyuki has quit [Ping timeout: 480 seconds]
<robertfoss>
robclark, lumag_ I'm booting the downstream aosp kernel for qcom sm8350, and I'm not seeing any calls to sde_kms_commit(), do you have any idea why I wouldnt see it being called?
<jfalempe>
tzimmermann, I just pushed the 3 mga damage patches on drm-misc-next, let me know if I did something wrong.
<lumag_>
robertfoss, #freedreno might be a better place to ask that ;-)
<robertfoss>
ack
ishitatsuyuki_ has joined #dri-devel
ishitatsuyuki has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
exit70[m] has joined #dri-devel
<marex>
lynxeye: robertfoss: do you think we can still get the tc358767 DSI-to-DP mode into 5.19.y or is it too late ?
<marex>
yesterday I tested it with new adapter board with 2-lane DSI and it just ... works
pnowack has joined #dri-devel
lileo has joined #dri-devel
lileo has quit []
lileo___ has quit []
lileo has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
lileo has quit []
lileo has joined #dri-devel
ella-0[m] has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
konstantin has joined #dri-devel
sdutt has joined #dri-devel
jagan_ has quit [Remote host closed the connection]
mszyprow has quit [Ping timeout: 480 seconds]
DottorLeo has joined #dri-devel
<DottorLeo>
hi! Is Gert Wollny here? :)
Mis012[m] has joined #dri-devel
mbrost has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
<robertfoss>
marex: do you mean "tc358767: Fix for eDP and DP DT endpoint parsing"?
<robertfoss>
if so, it was included in the may 5th drm-misc-next pull request
<DottorLeo>
Venemo, do you still have a GFX6 card? :)
<Venemo>
DottorLeo: yes
<DottorLeo>
A renderdoc capture will play indipendently from the card, right? Example if i capture a trace with a GFX6 card do i need it on another machine to test that trace?
<karolherbst>
I think you might want to play around with that and see if we can also drop opencl-c.h for the USE_STATIC_OPENCL_C_H path
devilhorns has quit []
<jenatali>
Yeah, we should be able to
<karolherbst>
you need this one LLVM change though, but I've put a link into the relevant commit
<jenatali>
It's the same thing, it's just that we embed the header in the compiler rather than having it on the end user's filesystem
<karolherbst>
right
jekstrand has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
LaughingMan[m] has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
nchery has joined #dri-devel
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
cheako has joined #dri-devel
<karolherbst>
ehh, why did I end up with 127 images
mszyprow has quit [Ping timeout: 480 seconds]
ralf1307[theythem][m] has joined #dri-devel
<cheako>
For https://docs.mesa3d.org/envvars.html I'm having trouble knowing what's "better", like is `RADV_DEBUG=llvm` an improvement(seriously asking)? Obviously, some options would be "an attempt to improve things" while others are "this is a legacy mode". `RADV_PERFTEST=rt` is an example of something "better", what about `RADV_PERFTEST=sam` I'm seriously asking?
<cheako>
May I suggest having separate variables, `RADV_TEST` and `RADV_DISABLE` I think this makes clear that one enables some testing mode while the other is for disabling some newly exposed feature. The current situations seems random.
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
dj-death has quit [Ping timeout: 480 seconds]
dj-death has joined #dri-devel
mclasen has joined #dri-devel
jekstrand has joined #dri-devel
jekstrand is now known as Guest534
jekstrand has joined #dri-devel
Guest534 has quit []
jekstrand has quit []
jekstrand has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
mr-nice has joined #dri-devel
mvlad has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
Danct12 has quit [Quit: Quitting]
plombo has joined #dri-devel
<karolherbst>
jekstrand: mhh, we have a small issue with the image counting stuff. So nir_gather_info uses image vars to count num_images, but the cl image lowering pass explicitly checks for wr_images
<karolherbst>
so I have the situation where gather_info overwrites values
<jekstrand>
karolherbst: Yeah... don't use num_images
<karolherbst>
well.. iris does :)
<jekstrand>
Use BITSET_COUNT(images_used)
<karolherbst>
ahh
<jekstrand>
karolherbst: Maybe we need to fix iris?
<jekstrand>
To use either BITSET_COUNT or BITSET_LAST_BIT as appropriate
<karolherbst>
I should give nouveau another go tomorrow now that I properly set READ/WRITE for maps
<karolherbst>
there was still some weirdo issue, but it looked way better with that
<jekstrand>
karolherbst: We can probably go one step further and use images_used instead of the manual scraping that iris does today.
<pendingchaos>
cheako: none of them are clearly better (some of them are generally or almost always worse)
<pendingchaos>
RADV_PERFTEST is usually for testing possible future changes that are not ready or we're not sure we want and RADV_DEBUG is everything else
<karolherbst>
I think I should focus on getting lp to pass :D
<jekstrand>
sounds good
<karolherbst>
ehh let me force it to be a GPU and see what's left to fix
plombo has quit [Ping timeout: 480 seconds]
mairacanal[m] has joined #dri-devel
neonking has quit [Remote host closed the connection]
<karolherbst>
I have to talke with airlied about that spir-v stuff in LLVMs header I think
<karolherbst>
we should fix this before the llvm-15 release
<jekstrand>
Yeah, we should if we can
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
<karolherbst>
meson question: if I want to set a target only in one if branch to something real, what should I set it to in the else branch to make it easy to use?
mr-nice has quit []
dj-death has quit [Ping timeout: 480 seconds]
<karolherbst>
ahhhhh crap
<karolherbst>
I'm using a broken kernel again :( forgot my i915 patch and of course it crashed the machine :)
<airlied>
karolherbst: uggh yeah no you want to talk to clang opencl ppl about that :-P
<airlied>
the options given in the past weren't very appealing :-P
<karolherbst>
airlied: they fixed my half issue with -base.h, maybe the'll fix this one as well :P
<karolherbst>
but yeah...
<karolherbst>
airlied: what are the options btw?
YaLTeR[m] has joined #dri-devel
<graphitemaster>
it's incredible how the general public thinks just because nv open sourced their kernel mode driver that nv graphics on linux will get better over night.
doras has joined #dri-devel
<graphitemaster>
i made the cardinal mistake of reading internet forums full of regular people
<graphitemaster>
someone getting down voted that it'll be years before we see any progress from such opening xd
rasterman has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
ramacassis[m] has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
lanodan has quit [Quit: WeeChat 3.4.1]
lanodan has joined #dri-devel
<karolherbst>
graphitemaster: :D
<karolherbst>
airlied: thanks
<karolherbst>
graphitemaster: there are enough annoying people there
<karolherbst>
I got blocked, because I pointed out that somebody is wrong about how RH operates, so...
icecream95 has joined #dri-devel
nchery has joined #dri-devel
dhanuka[m] has joined #dri-devel
ngcortes has joined #dri-devel
undvasistas[m] has joined #dri-devel
<jekstrand>
bnieuwenhuizen: Are stencil images on AMD basically just color?
<jekstrand>
bnieuwenhuizen: Trying to grok the image transition code
<bnieuwenhuizen>
no
<bnieuwenhuizen>
it is kinda R8, but a different tiling mode, and using HTILE for compression
<bnieuwenhuizen>
+ some weirdness because pre-GFX9 it has to share a stride with the depth image
<jekstrand>
Ok, then the vk_format_has_depth() check in radv_handle_image_transition has me very confused.
<bnieuwenhuizen>
you may have found a bug, or in practice we never end up compressing a S8-only image. Let me check the latter
dj-death has joined #dri-devel
<karolherbst>
airlied: I'll try to write something up and file a bug on the bug tracker. Should be easier to follow there. Maybe I even drop some code if I have a good idea on how to solve this
<karolherbst>
airlied: I have an idea...
<bnieuwenhuizen>
jekstrand: we may end up never compression a plain S8 image and hence no transitions needed, which hid the bug
<bnieuwenhuizen>
never compressing*
<karolherbst>
"PASSED sub-test." mhhhh
<karolherbst>
interesting
<cheako>
pendingchaos: When you say "some of them"... that's exactly what I'm asking, "which ones." It's not clear from the documentation for any of the examples *what they are. * Just the distinction of future "attempted" improvements or past code available for a stable workaround.
Danct12 has joined #dri-devel
<bnieuwenhuizen>
cheako: RADV_PERFTEST is experimental stuff that may or may not improve things (though in general either not stable or not improving things) and RADV_DEBUG is for debugging & workarounds
<airlied>
karolherbst: my idea was for them not do that in the header file :-P
<karolherbst>
yeah... should be straightforward
<karolherbst>
but I think I'll have something which could work from within mesa...
<karolherbst>
airlied: so we could add a spirv lib target thing which just doesn't add those defines
<karolherbst>
but that sounds messy to add
<cheako>
bnieuwenhuizen: That sounds correct... What I found confusing is the names, I didn't understand the meaning and the documentation seems to be making an assumption that the reader should already know this distinction.
<karolherbst>
I am sure it's something terrible weird in my llvm build
<karolherbst>
anarsoul: I am disappointed it's C
<karolherbst>
don't waste perfectly good names for rust projects on c ones
<karolherbst>
:D
<icecream95>
Fun.. llvmpipe seems to get into an infinite loop for SuperTuxKart with Mesa 22.0.1 and LLVM 13.0.1
<anarsoul>
karolherbst: what a waste for a nice project name? :)
<karolherbst>
there is a special place for people wasting project names like this
<anarsoul>
karolherbst: in Samuel's defence, the project was started in 2017, that's way before rust became so popular
<jekstrand>
airlied: I'll need unsafe {} if I'm going to call my hand-JIT AVX2 code. :P
<airlied>
jekstrand: sure rust could do it with a crate :-P
<jekstrand>
airlied: Probably...
* karolherbst
shouldn't count how often rusticl uses unsafe
<karolherbst>
okay.. how many of those 35 fails do I have to fix
<karolherbst>
18
<karolherbst>
airlied: those allocation tests are a bit odd and I have no idea why those fail tbh
<karolherbst>
Attempting to allocate a 2047.92MB read-only image (11585 x 11585) and fill with blocking writes. that fails and then it retries with 11217 x 11217 which works
<karolherbst>
but the checksum doesn't match and I suspect it's because of that retry
<karolherbst>
let me see why it actually fails
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]