ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
ybogdano has quit [Ping timeout: 480 seconds]
stuarts has quit []
apinheiro has quit [Quit: Leaving]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
genpaku has quit [Ping timeout: 480 seconds]
genpaku has joined #dri-devel
icmroortideotm^ has quit [Remote host closed the connection]
mbrost has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
danilo has quit []
dakr has joined #dri-devel
rmckeever has quit [Quit: Leaving]
yuq825 has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
krushia has quit [Quit: Konversation terminated!]
binhani has quit [Quit: Konversation terminated!]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
camus has quit []
camus has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
krushia has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
krushia has quit [Quit: Konversation terminated!]
krushia has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
Dr_Who has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ngcortes has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<clever>
MrCooper: after some more experimentation, ctrl+z on chrome, and memory pressure, doesnt push chrome out of vram, and performance is still poor
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
<clever>
i suspect a large chunk of the game was in GTT and wasnt moving back upon closing chrome, will need to analyze amdgpu_gem_info more
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
godvino has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
khfeng_ has quit []
agd5f has joined #dri-devel
godvino has quit [Quit: WeeChat 3.6]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
smiles_1111 has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
agd5f_ has quit [Read error: No route to host]
agd5f_ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Read error: Connection reset by peer]
agd5f_ has joined #dri-devel
Zopolis4 has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
smiles_1111 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
<tarceri>
mareko: well it should be but it been talked about before and never implemented
kzd has joined #dri-devel
mbrost__ has quit [Remote host closed the connection]
mbrost__ has joined #dri-devel
lemonzest has joined #dri-devel
mbrost__ has quit []
tzimmermann has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
danvet has joined #dri-devel
itoral has joined #dri-devel
bgs has joined #dri-devel
Zopolis4 has quit []
godvino has quit [Quit: WeeChat 3.6]
Duke`` has joined #dri-devel
godvino has joined #dri-devel
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
godvino has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
frieder has joined #dri-devel
godvino has joined #dri-devel
ice9 has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
pochu has joined #dri-devel
tursulin has joined #dri-devel
dtmrzgl has quit []
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
<javierm>
tzimmermann: where are still discussing the bug for SDDM and missing simpledrm with "nomodeset" due a VESA mode not being set
<javierm>
tzimmermann: how do you handle that in OpenSUSE? I think you use SDDM/KDE too?
<javierm>
tzimmermann: so probably a regression in fedora's grub then
<tzimmermann>
IIRC GRUB_TERMINAL=gfxterm
<javierm>
but that wouldn't help in your install media that boots using syslinux right ?
<tzimmermann>
it sounds as if your grub runs in va text mode. don't expect vesa then
<tzimmermann>
our syslinux also uses graphics by default
<tzimmermann>
or it gives an option to select a graphics mode
<javierm>
tzimmermann: yes, but I tried with GRUB_TERMINAL=gfxterm too and it didn't work either
<javierm>
also doing insmod vbe, setting a gfxmode, etc
<javierm>
tzimmermann: anyways, you are relying on grub to set the mode then and it works. That explains why is not an issue for your
<javierm>
*you
<javierm>
normal fedora workstation images use Gnome and GDM fallbacks to X11 that uses the vesa DDX so that works too
<tzimmermann>
the bootloader: grub/syslinux
<javierm>
but it seems SDDM/KDE doesn't fallback to X11 when using wayland and that's how this bug is triggered
<tzimmermann>
as dicussed in the bugreport, maybe enable graphics by default.
<tzimmermann>
i don't know the internals of syslinux, but there is a way of setting the display mode or setting vga=
lynxeye has joined #dri-devel
<javierm>
tzimmermann: problem with vga= is that it seems the modes are not consistent accross machines
<javierm>
at least according to fedora QA vga=ask list different numbers for the same modes
<tzimmermann>
javierm, maybe thesemodes have different timings?
<javierm>
hmm, it seems that's only for 32-bit palette but 16-bit and 24-bit are "standard" modes and those are the same on all BIOS
<javierm>
not really that familiar with VESA and VBE :)
<javierm>
tzimmermann: but all this shows me that maybe there's a need for a vesadrm driver that could expose the supported modes and let user-space set one
<tzimmermann>
javierm, how did it work with efifb?
<javierm>
tzimmermann: for efifb it works because the EFI stub uses the EFI-GOP runtime service to get the resolution and framebuffer
<javierm>
and same for simpledrm with EFI
<tzimmermann>
sorry i meant vesafb. that problem must have been present before
<javierm>
tzimmermann: yes, it never worked for vesafb either
<tzimmermann>
and in your bug report, it is said that sddm requires x11
<javierm>
tzimmermann: Gnome doesn't have a fbdev wayland backend and SDMM was using X11 before too AFAIU
<tzimmermann>
IIRC we can blacklist certain userspace or drivers in opensuse for wayland use
<javierm>
so in both cases it was vgacon -> X11 with user-space VESA DDX
<javierm>
vesafb was only used with a proper VESA mode (which in fedora was only vga= due grub being boot in text mode)
<tzimmermann>
and you cannot go back to this setup for sddm?
ice9 has joined #dri-devel
devilhorns has joined #dri-devel
rasterman has joined #dri-devel
<tzimmermann>
javierm, the vga= value is 0x200 + the vesa code. so vga=318 should give 1024x768
<javierm>
tzimmermann: I'm not familiar with SDDM but for some reasons it seems that does not fallback to X11 when no dri device is found?
<javierm>
tzimmermann: ahh, interesting
<tzimmermann>
no idea about sddm
<tzimmermann>
if you wan tto debug, maybe set up a 32-bit qemu and run the live cd
<javierm>
tzimmermann: 32-bit qemu does work
<javierm>
tzimmermann: ah, you meant for SDDM? Not really that interested in that part
<tzimmermann>
javier, see that pdf under 'VBE mode numbers'
<tzimmermann>
and accoring to the linux docs, 0x200 needs to be added
<javierm>
tzimmermann: vga=791 (hex 0x317 that is 1024x768x16) does work on all machines it seems
<tzimmermann>
ok
<javierm>
117h - 1024x768 64K (5:6:5) in your table
<tzimmermann>
maybe i got the syntax wrong
<javierm>
tzimmermann: no, you are correct. It's just that vga= for some reasons expect a decimal value why vga=ask list in hex and the table is in hex too
<javierm>
consistency ftw :)
<tzimmermann>
oh :/
<tzimmermann>
that's what i'd tell to users.
srslypascal has joined #dri-devel
<javierm>
tzimmermann: anyways, this is very useful info. So I'll suggest them to either 1) just set vga=791 along with nomodeset for this "safe graphics mode" or 2) change the bootloader config to gfxterm and let grub set it
<tzimmermann>
or maybe hardcode that vga= resolution. :) if the card doesn't support it, you probably don't want to run kde on it
<javierm>
tzimmermann: yeah, that's what I meant by option (1). That the tool doing the install images hardcode that vga= resolution in the "safe graphics mode" boot entry
<javierm>
tzimmermann: I'll explore though typing a vesadrm driver, not related to this bug but just for fun and to learn more about VESA and VBE :)
<tzimmermann>
one of the problems is that all this vesa stuff has been dead and unmaintained for 20yrs. the vesa pdf is (c) 1998. supporting it is really best-effort at this point.
<javierm>
tzimmermann: yeah, but still we have some level of support with this vga= param
<javierm>
so my idea was just to use that mode get/set logic for a vesadrm
<javierm>
or do you think is not really worth the effort?
<tzimmermann>
is that possible from within the kernel?
<javierm>
but also a kernel driver calling a user-space program seems risky
<javierm>
so yeah, probably we want to stay away from anything related to VESA and VBE
<javierm>
tzimmermann: it seems you are correct and vesa modes can't be changed once in protected mode
<javierm>
there seems that VBE 2.0 has support but isn't well documented as you said and no BIOS really implement it
<javierm>
tzimmermann: anyways, I'll suggest them setting a vga= and call it a day :)
fab has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
ice9 has quit [Read error: Connection reset by peer]
<vliaskov>
When using virtio or qxl driver in a VM and the display is flipped, the cursor is not drawn in the correct coordinates (https://gitlab.gnome.org/GNOME/mutter/-/issues/2692). Happens on both gnome and kde. Is it reasonable to view this as a driver issue? Is there a recommended way to correctly update cursor coordinates for virt drivers? E.g. with a plane rotation property and a relevant drm helper function?
ice9 has joined #dri-devel
srslypascal has joined #dri-devel
<jadahl>
vliaskov: arguably one shouldn't need to special case virt drivers
hansg has joined #dri-devel
mohamexiety has joined #dri-devel
<mohamexiety>
does deqp-runner allow choosing a particular device to run on?
sgruszka has joined #dri-devel
kts has joined #dri-devel
<mohamexiety>
yep, through --deqp-vk-device-id. my bad.
illwieckz has quit [Read error: Connection reset by peer]
illwieckz has joined #dri-devel
Zopolis4 has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
yuq825 has quit []
koike4 has joined #dri-devel
koike4 has left #dri-devel [#dri-devel]
koike has joined #dri-devel
elongbug has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<koike>
Hi zmike, I was checking with DavidHeidelberg[m] regarding this discussion https://oftc.irclog.whitequark.org/dri-devel/2023-03-21 . You mentioned those weren't flakes, but I noticed on every zink-freedreno-a630-traces job reported as flake, there is a passing job on the same commit. For instance this one:
<koike>
https://gitlab.freedesktop.org/mesa/mesa/-/jobs/38428751 there is a passing job on the same commit, so it is classified as flake (since there is a failing and a passing job without any changes on the code). Am I missing something?
<Hazematman>
If developers on those drivers are able to review my changes (its only a couple lines per driver to add a common feature to every gallium driver) I would greatly appreciate it!
pjakobsson has joined #dri-devel
godvino has joined #dri-devel
yuq825 has joined #dri-devel
<ice9>
some apps fail to work throwing this error: libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
mohamexiety has quit [Quit: Konversation terminated!]
ice9 has quit [Read error: Connection reset by peer]
ice99 has joined #dri-devel
Guest8376 has quit []
<zmike>
koike: it looks to me like this is a godot trace timeout. the discussion you're referencing was about source games
Danct12 has joined #dri-devel
itoral has quit [Remote host closed the connection]
godvino has quit [Quit: WeeChat 3.6]
ice99 has quit [Read error: Connection reset by peer]
Zopolis4 has quit []
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
devilhorns has quit []
lemonzest has quit [Read error: Connection reset by peer]
lemonzest1 has joined #dri-devel
ice9 has joined #dri-devel
Company has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<tlwoerner>
... and binhani is gone
<koike>
zmike right. The report is getting all the pipelines that were assigned to Marge, even if it didn't get merged, so probably those are errors from previous versions of the code on a MR.
<zmike>
yes probably
<DavidHeidelberg[m]>
btw. looking into the pipelines, these succeeded
<DavidHeidelberg[m]>
The flakes Valve flakes aren't related only to your MR and the runs are final.
<zmike>
yeah they were deadlocking during the initial runs
<zmike>
I had to fix some issues
<koike>
DavidHeidelberg[m]: fyi, this is the MR from the error I pointed above https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22025 , there are multiple runs from Marge. let's see if I can improve the report so we remove this false positives
<DavidHeidelberg[m]>
zmike: ok, I understand :) thanks
srslypascal has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
zmike: btw. PenumbraOverture started crashing frequently on zink, are you aware? should I create an issue?
<zmike>
yes, I think it should be resolved by !22054
<DavidHeidelberg[m]>
hehe, the most important job to test is in "pending" state :D
<zmike>
surely one day it will run
<DavidHeidelberg[m]>
He found the secret how to make the job run. You won't believed!
<zmike>
CI experts HATE this one weird trick!
<DavidHeidelberg[m]>
:D better
<DavidHeidelberg[m]>
(it's the GitLab bug you have to retry any job from same farm, and GL starts sending jobs to the runners again)
<zmike>
incredible
* DavidHeidelberg[m]
want to say disclaimer: it's not our CI bug :D
fxkamd has quit []
fxkamd has joined #dri-devel
mohamexiety has joined #dri-devel
<jenatali>
So I was trying to use ci_run_and_monitor.py last night and wasn't able to find an environment where I could get it to work
<jenatali>
What Python version are people normally running that with?
pzanoni has quit [Ping timeout: 480 seconds]
<daniels>
jenatali: oh ... I've just realised your mistake - pip3 install --user python-gitlab, not just 'gitlab'
aswar002 has quit [Ping timeout: 480 seconds]
<daniels>
(personally I'm on Python 3.11 but I've never had a problem with the gitlab module not working on anything for the last 5-6 years)
<jenatali>
Oh, obviously (sarcasm). But seriously, thanks I'll try it out
unerlige has quit [Ping timeout: 480 seconds]
rsripada has joined #dri-devel
pzanoni has joined #dri-devel
<jenatali>
I just assumed that import gitlab meant I needed a package named gitlab
aswar002 has joined #dri-devel
dolphin has quit [Ping timeout: 480 seconds]
sghuge_ has joined #dri-devel
unerlige has joined #dri-devel
sghuge has quit [Remote host closed the connection]
dolphin has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
rsripada_ has quit [Ping timeout: 480 seconds]
mohamexiety has quit []
<daniels>
yeah, that's a reasonable assumption, but also not true for pypi
<jenatali>
daniels: Was there a piece of documentation I missed that said that btw?
<daniels>
jenatali: errr ... IRC backlog?
<jenatali>
Heh, got it
<jenatali>
Could be worth a comment at the top of the script to call out which packages are needed for deps at least
<daniels>
DavidHeidelberg[m]: ^
srslypascal has joined #dri-devel
<DavidHeidelberg[m]>
Hmm, I had this idea, but it was transferred to `requirements.txt`
ella-0 has quit [Remote host closed the connection]
kchibisov has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
sumoon_ has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
fab has quit [Quit: fab]
kchibisov has joined #dri-devel
sumoon has joined #dri-devel
kennylevinsen has joined #dri-devel
ella-0 has joined #dri-devel
rpigott has joined #dri-devel
ifreund has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<DavidHeidelberg[m]>
It's not that intuitive, but in Python world it is kinda default
frieder has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah but for people running the script rather than authoring it, they might not be familiar with the Python world
frieder has joined #dri-devel
Haaninjo has joined #dri-devel
<danylo>
Could someone review the changes to common VK code from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21931 ? TLDR: In turnip we want to make vk common code to work nice with c++, there are a few trivial changes and two bigger ones: "vk/util: Generate defines to help casting structs with vk_find_struct" and "vk/entry_points: Add option to generate template entrypoints"
<jenatali>
Danylo: I looked at most of it and was happy with it, especially the casting, but I didn't follow the template entrypoint bits... I should take another look
<danylo>
thanks!
fab has joined #dri-devel
agd5f_ has quit []
agd5f has joined #dri-devel
agd5f has quit []
agd5f has joined #dri-devel
kzd has joined #dri-devel
kts has joined #dri-devel
ella-0 has quit [Remote host closed the connection]
kchibisov has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
ifreund has joined #dri-devel
kchibisov has joined #dri-devel
ella-0 has joined #dri-devel
kennylevinsen has joined #dri-devel
rpigott has joined #dri-devel
sumoon has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
Duke`` has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
jenatali: I'm aware, maybe there could be mention of `requirements.txt` in the header?
Net147 has joined #dri-devel
<jenatali>
David Heidelberg: Sounds like a good idea to me
shashanks_ has joined #dri-devel
shashanks is now known as Guest8561
shashanks_ is now known as shashanks
Guest8561 has quit []
sgruszka has quit [Ping timeout: 480 seconds]
shashanks has quit []
shashanks has joined #dri-devel
shashanks has quit []
shashanks has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
tursulin has quit [Ping timeout: 480 seconds]
shashanks has quit [Remote host closed the connection]
<tjaalton>
any idea about the progress of mesa 23.0.1?
<tjaalton>
new stuff keeps getting added to staging
<tjaalton>
and it's been four weeks since 23.0.0 already..
Scorpi has joined #dri-devel
iive has joined #dri-devel
<pepp>
MrCooper: do you have a link to the dri3 patches you mentionned yesterday please?
sghuge_ has quit []
sghuge has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
cef has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
<MrCooper>
pepp: err, can you remind me where I mentioned something about DRI3 patches? :)
cef has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
smiles_1111 has quit [Ping timeout: 480 seconds]
jpy794 has joined #dri-devel
<pepp>
MrCooper: yesterday morning "that is because the DRM file descriptor for DRI3 clients is opened by X, there are pending patches which will name the DRI3 clients instead"