ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Haaninjo has quit [Quit: Ex-Chat]
flto has quit [Read error: Connection reset by peer]
flto has joined #dri-devel
pcercuei has quit [Quit: dodo]
jewins has joined #dri-devel
flto has quit [Read error: Connection reset by peer]
flto has joined #dri-devel
join_subline has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
eukara has quit []
<cheako>
daniels: I took a look at the BTS and it took me a while to figure out what I was going to do about what I saw there. Firstly, you should take a good look so you've an informed position if nothing else. The BTS does not look like an effective method for getting even the most basic levels of assistance, just by reading the titles I was able to assist with two issues over the last 3 months. So it's an effective resource for being
<cheako>
ignored. Secondly, and because of this, it's going to become an unmanageable mess if nobody even reads them and someone should take a look.
tarceri has joined #dri-devel
eukara has joined #dri-devel
<alyssa>
cheako: What are you getting at?
co1umbarius has joined #dri-devel
<tarceri>
I miss the days when merging was a command line away
columbarius has quit [Ping timeout: 480 seconds]
<alyssa>
tarceri: relatable
<alyssa>
on the other hand my driver was an unstable unusable mess then so i guess i can't miss it too hrad
<alyssa>
hard
<tarceri>
:) I like CI but man this has been flaky
<tarceri>
no disrespect to those working on it either, just frustrating that its falling over all the time
<tarceri>
alyssa: I don't know how it works, all I know is marge won't merge for days at a time and its frustrating.
guru_ has joined #dri-devel
guru_ has quit []
<zmike>
yea there was a hiccup this weekend of sort where merges weren't going through
<zmike>
I merged something earlier though so I think it's fixed
oneforall2 has quit [Ping timeout: 480 seconds]
maxzor has quit [Quit: Leaving]
jewins has quit [Ping timeout: 480 seconds]
cphealy has joined #dri-devel
<tarceri>
zmike: still not working for me, I did see that you got something through
bbrezillon has joined #dri-devel
<zmike>
:/
<zmike>
tarceri: my strategy is usually when something fails like this I'll just try again the next day
<zmike>
frustrating, but lot of v smart people working on it so problems usually get fixed pretty quick
bbrezill1 has quit [Ping timeout: 480 seconds]
<tarceri>
zmike: it is the next day :P anyway as above no disrespect to those working on it they have done a great job. I suspect being in a different timezone from just about everyone I probably get unlucky and hit problems while everyone is asleep/enjoying their lives doing non mesa things
<zmike>
I usually try to do a lot of my merging in your tz because things usually work better then :P
<zmike>
less congestion
<zmike>
but weekends are also tough
<airlied>
need to design a self repairing system :-P
<zmike>
sounds like a job for you-know-who
<airlied>
Sun/Mon .au time is the worst, since generally it's fallen over in the weeds on Saturday :-P
<airlied>
and I don't really feel like pushing disable half the CI without acks
<zmike>
I keep saying it but there should be like a CI concierge
<zmike>
or maybe just a channel
<zmike>
where people can list MRs they want marged and kind strangers can retry whenever they have a minute during rebuilds
rasetan has joined #dri-devel
<airlied>
I'd like a least some indication of whether it's dead or just slow somewhere
<airlied>
to avoid just reassigning random MRs until one stucks
<zmike>
gotta read through all the failure logs to find out
<zmike>
like a treasure hunt!
<tarceri>
haha
<rasetan>
So the discussion of yours surprisingly inconclusive, CPU Intel products with so many instructions overlay arithmetcs over one result forwarding bus with instant parallel selection to nr of banks so div is in different one than mul add, they combine them based of types to, so entirely based of what type and what arithmetic used you are delayed with one cycle if it's not the same bank to forward the result, earlier cores were more simple and had no suc
<rasetan>
And there I yestirday picked up news where rdna was integrated to arm docs with AMD collaborating with Nvidia who now owns arm stuff or any soc company can't remember, same was offered for multiisa CPUs by me, but the former yeah great idea too.
<rasetan>
So calling a supercheduler of dispatcher enabled chip like simd or vliw, goes to mark multiwave wg, which is always possible, internal crossbus module arbiters loaded, than limiting the wavefronts to zero or anything below what sibling module, like fetcher has in arb registers,makes scheduler to stall :)
<rasetan>
Err dispatcher
<rasetan>
I made the needed simulations but ring buffers were missing but I see the ring Isa it's simplest which will work great.
<jenatali>
I happened to see a MR that had timed-out CI that eventually passed and tried reassigning... But Marge didn't do anything with it and I don't understand why
<rasetan>
And why I even talk this to you is only my genuine respect for you making the drivers regardless of the genuine disrespect you have towards me added also that I am surveillanced and my code would leak anyway, but I would had given it to you regardless for the reason outlined in the first part of the sentence.
<airlied>
jenatali: I think there is a corner case where if nothing else gets merged in between
<airlied>
marge won't do a rebase
<airlied>
so you have to manually retry the pipeline
<airlied>
it does look like at least the amd deviecs in CI are down
<jenatali>
Oh if it's sitting already passed rather than still in progress
maxzor has joined #dri-devel
<imirkin>
computers need to take weekends off too...
<imirkin>
always loved those gov't websites that say they're only available 9-5 weekdays...
maxzor has quit []
maxzor has joined #dri-devel
<HdkR>
Government jobs listening to "Working for the weekend" too much
<anholt>
airlied: is it really given a test result of "Info", or are we mis-parsing something else?
<airlied>
anholt: haven't dug into the qpa file yet
<airlied>
btw the error msg says .log but I think the file on disk is .qpa
<rasetan>
So as you think about this, prioritising ring packets to cause dispatcher to stall is meant to be performance feature to hide the latency, so only way to block it is to fragment the waves and test it with conditional in which this totally nuts case you'd end up cracking up easily the inverter with a bus back, there is no way to get away limiting perf hence.
<anholt>
airlied: we should be storing the stderr/stdout in the .log file at that path
<airlied>
I don't see that
<rasetan>
To test what opcodes ring sends on full band in circumstances would require incredible resources for another decoder added totally impossible
<anholt>
thinking of new vk cts, could you please ack the llvm assert removal so we can at least get to 1.2.8.0?
<rasetan>
As to block the shader opcodes to land on request evilly.
* anholt
does wonder when we get cts 1.3
<Sachiel>
Soon™
<rasetan>
In other words aside from simple inverter to block reprogramming the threads if halt is not met, the dispatcher and decoders would make the chip 10 times larger, and due to performance the inverter based fuse is undisirable.
<rasetan>
So it really is going to work that hack as seen from dx12 and vulkan apis.
<airlied>
anholt: looking
<jekstrand>
1.3 or bust!
<rasetan>
As with regulating voltsge by leaking inverter ones to bus can control anything like as gpu was fpga you can program gpu to execute also arm or x86 code totally in hw with insane perf, so rdna and equipment is nuts but on arm you first get the access of the most insanest gpu on phones or tablets.
<rasetan>
This is big blow as said this hw is something I would really want to have.
<airlied>
anholt: ah yes *that* assert
<airlied>
okay let me go reproduce it and see what I can convince myself of
<rasetan>
You end up with 200 CPU core machine equivalent on freaking phone, capable of running x86 Photoshop with ease, I know gcn the best, but any gpu can do the last.
<rasetan>
But as x86 is claimed to be property Ida wise of Intel in SW the fallback fast hash method exist also to overcome that claim, but imo hw rights they do not have, it should be legal to program fpga or asic to execute x86.
<rasetan>
Totally insane, Samsung low power cross Isa homebrew incorporating 600 extreme low voltage cores on 4nm, so this is how insane the tech is today, a freaking tablet like this.
<rasetan>
Samsung was the partner of amd I remember now.
<ishitatsuyuki>
lol hammered
<maxzor>
who struck the Lithuanian
<ishitatsuyuki>
I'm wondering why mpv is slow at seeking when using vaapi
<ishitatsuyuki>
The video is a zoom recording and has very long keyframe intervals to save space
<ishitatsuyuki>
Is it just the latency from issuing GPU commands or could it be some bug?
<ishitatsuyuki>
software decoding seeks are nearly instant in comparison
* airlied
is failing to find tests the trigger assert of course
<anholt>
are you running virgl with llvmpipe as the vtest backend?
<anholt>
that was where it was failing
<anholt>
though actually I suppose given the current state of things it's crosvm+virglrenderer
<airlied>
anholt: nope I was hoping to not have to go through all of that to find a failure, I was sure I've seen one in the past without virgl
<airlied>
but am failing to reproduce it
Duke`` has joined #dri-devel
<airlied>
anholt: got some more on the Info
<airlied>
Test case 'dEQP-VK.api.buffer_memory_requirements.create_sparse_binding_sparse_residency_sparse_aliased.ext_mem_flags_included.method1.size_req_transfer_usage_bits'.. Info (Create buffer with VK_BUFFER_CREATE_SPARSE_BINDING_BIT not supported by device at vktApiBufferMemoryRequirementsTests.cpp:353)
<airlied>
Info (Create buffer with VK_BUFFER_CREATE_SPARSE_BINDING_BIT not supported by device at vktApiBufferMemoryRequirementsTests.cpp:353)
<anholt>
sounds like it's a Skip, then?
<airlied>
yeah seems like a NotSupported
<anholt>
throw up an issue in the repo if you don't want to do a quick mr? trying not to get sucked into mesa tonight.
<airlied>
looks specific to that test
<airlied>
not an overall deqp thing
<anholt>
khr-gl also has some oddball test statuses it uses in a couple tests.
<anholt>
but this feels like someone just grabbed the wrong one tbh
<airlied>
they are emitted it directly in the code
<airlied>
okay filed an issue, no hurry, I'm going to hack the cts to remove them for now
<anholt>
i'm sure upstream would say we should be parsing qpas instead, if anything, but we really do want to understand these test statuses because we're trying to coalesce the meanings of them into a few things.
eukara has quit [Remote host closed the connection]
itoral has joined #dri-devel
eukara has joined #dri-devel
mszyprow has joined #dri-devel
frytaped has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
frieder has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
shankaru has joined #dri-devel
arnd_ has quit []
arnd has joined #dri-devel
ahajda_ has joined #dri-devel
<tpalli>
there seems to be some trouble going on with Mesa ci, marge says that ci failed but I think it is just timing out
mlankhorst has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
danvet has joined #dri-devel
MajorBiscuit has joined #dri-devel
mvlad has joined #dri-devel
tzimmermann has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
mvlad is now known as Guest1222
maxzor_ has joined #dri-devel
jfalempe_ has joined #dri-devel
mvlad has joined #dri-devel
V_ has joined #dri-devel
CME_ has joined #dri-devel
jcristau_ has joined #dri-devel
Major_Biscuit has joined #dri-devel
q66_ has joined #dri-devel
CounterPillow_ has joined #dri-devel
hakzsam_ has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
mupuf_ has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
Guest1222 has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
jfalempe has quit [Ping timeout: 480 seconds]
hakzsam_ has left #dri-devel [#dri-devel]
hakzsam has joined #dri-devel
mupuf_ has quit []
mupuf has joined #dri-devel
danvet has joined #dri-devel
tursulin has joined #dri-devel
zamundaaa has joined #dri-devel
pcercuei has joined #dri-devel
abhinav____ has joined #dri-devel
robher has quit [Ping timeout: 480 seconds]
abhinav___ has quit [Ping timeout: 480 seconds]
abhinav____ is now known as abhinav___
robher has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
undvasistas[m] has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
jcristau_ is now known as jcristau
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
rasterman has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
frytaped has quit [Quit: frytaped]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
<javierm>
tzimmermann: I believe that user-space should cope with a not known connector type? i.e: what Noralf mentions about Xorg and Weston in commit ("fc06bf1d76d6 drm: Add SPI connector type")
<pq>
It's almost funny: the monitor tells PC what it can do, and then the monitor will NOT mangle the video signal.
thaytan has quit [Ping timeout: 480 seconds]
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
lemonzest has joined #dri-devel
jfalempe_ has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
Venemo has joined #dri-devel
yshui` has joined #dri-devel
<daniels>
tarceri: yeah in all honesty 2am on Sunday night / Monday morning isn't the time when people are most responsive to stuff ... apparently though all the machines were fine, the job scheduler fell over and wasn't pushing any new jobs through, which caused a bunch of monitoring to send a bunch of alerts to people who were asleep :\
thellstrom has quit [Quit: thellstrom]
Company has quit [Ping timeout: 480 seconds]
<tarceri>
daniels: :) They do say earlier adopters should expect to hit a few bumps so I guess that applies those of us living in the future
Strit[m] has joined #dri-devel
<tarceri>
as dave said Monday is not the best day to merge au time
jfalempe has joined #dri-devel
<daniels>
haha
whald has joined #dri-devel
Company has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
devilhorns has joined #dri-devel
agx has joined #dri-devel
shankaru has quit [Quit: Leaving.]
oneforall2 has joined #dri-devel
agd5f_ has joined #dri-devel
PiGLDN[m] has joined #dri-devel
karolherbst has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
whald has quit [Remote host closed the connection]
The_Company has quit []
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit []
MajorBiscuit has joined #dri-devel
jewins has joined #dri-devel
dafna2[m] has joined #dri-devel
fxkamd has joined #dri-devel
nsneck has quit [Quit: bye]
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
MajorBiscuit has quit [Quit: WeeChat 3.4]
MajorBiscuit has joined #dri-devel
nsneck has joined #dri-devel
agd5f_ has quit [Remote host closed the connection]
agd5f has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.4]
MajorBiscuit has joined #dri-devel
shankaru has joined #dri-devel
heat has quit [Remote host closed the connection]
jenatali has joined #dri-devel
shankaru has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
sdutt has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
sdutt has quit []
sdutt has joined #dri-devel
tursulin has joined #dri-devel
Guest1044 is now known as jekstrand
<danvet>
javierm, the recent syzbot fix that says "video: vga16fb: Only probe for EGA and VGA 16 color graphic cards" fixes some entirely unrelated looking splat scares me :-/
<cwabbott>
seems like anv and radv both don't try to lookup anything in the cache after linking, which I'm a bit surprised by
<tzimmermann>
same here
<tzimmermann>
danvet ^
<danvet>
tzimmermann, maybe it'll come back with more drivers enabled now ...
<javierm>
danvet: yes, I think is because that driver was always probed without even checking if the machine had a EGA/VGA graphics card
<danvet>
orly?
<danvet>
javierm, it should still not blow up I think
<javierm>
danvet: agreed but the fact that now there's a check that prevents to be loaded unless is really a EGA/VGA 16 mode, masked the real issue
<cwabbott>
is that intentional? I'd think you'd get quite a few hits from pipelines just sharing FS or VS
<javierm>
because now the syzbot can't reach the buggy code in fbdev anymore
nchery has joined #dri-devel
<danvet>
yeah and vga16/ega is probably dead enough that we can stop to care
<javierm>
danvet: yeah. We already know that fb{dev,con} is a mine field. Even if people claim otherwise
<danvet>
the thing that also scares me is that fbcon locking is still fundamentally busted (see the FIXME in fbcon.c I put a while ago)
<danvet>
and I just spent last week screaming at it, and it's unfixable
<danvet>
yay
<danvet>
anyway I hope I can send out these roughly 20 patches or so
<danvet>
javierm, well something like a) remove_conflicting_framebuffers nukes the simple-framebuffer device and b) efifb et al check whether that's still there
<danvet>
javierm, I guess I can just wrap it up
<demarchi>
jani: danvet for string_helpers.h new functions (https://patchwork.freedesktop.org/series/99030/) the agreement was to merge the first patch on drm-misc. Any chance we can get that merged so we have a chance to get it on next backmerge to the other branches?
<javierm>
danvet: actually, I think tzimmermann already fixed this properly with commit 7599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
<javierm>
danvet: so AFAICT you can drop those checks now
<danvet>
demarchi, sure
<danvet>
grab a drm-misc committer and volunteer them :-)
<javierm>
danvet: better for tzimmermann to confirm if I'm not missing anything to avoid adding a regression. But I think that should work now that the devices are removed
<danvet>
javierm, I don't have that commit here?
<javierm>
danvet: ups, sorry was in another branch. Is 27599aacbaef in drm-misc-next
<danvet>
thx
<javierm>
demarchi: happy to help. Do you want me to push to drm-misc-next ? I haven't looked at the series but I see that's already acked by jani and danvet :)
<tzimmermann>
danvet, javierm, sorry, i#m pretty busy. what am i supposed to confirm?
<javierm>
tzimmermann: if commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") fixed the underlaying problem fixed by fb561bf9abde ("fbdev: Prevent probing generic drivers if a FB is already registered")
<javierm>
tzimmermann: because now a DRM driver will kick off the platform drivers and prevent generic fbdev drivers to probe
<javierm>
err, *kick off the platform devices
Surkow|laptop has joined #dri-devel
<javierm>
tzimmermann: there's no rush though. Sorry for disturbing you
<tzimmermann>
javierm, i think both issues are unrelated
<javierm>
tzimmermann: oh, right. Because sysfb cold register the plaform device *after* the DRM driver called remove_conflicting_framebuffers()...
<danvet>
I'll reorder the patches to make that and the cleanup the last two then
<tzimmermann>
removing drm drivers from fbdev is currently not possible. the best way would be a hock in fbdev that allows remove_conflicting_framebuffers to call into drm aperture helpers
<danvet>
tzimmermann, do we really care about that edge case?
<danvet>
that sounds like you have a native fbdev driver which wants to remove simpledrm
<danvet>
which sounds very backwards
<tzimmermann>
well, i don't. but i'm pretty sure someone out there...
<danvet>
javierm, can't we stop sysfb in that case?
<danvet>
or at least guarantee the sysfb pdev exists before we start loading drivers
<danvet>
or make sure it doesn't pop up when we tried to nuke it already
<javierm>
danvet: the problem is the following. 1) A real graphics device is registered, 2) the DRM driver matches and is probed, 3) sysfb register a simple-framebuffer pdev 4) the simple{fb,drm} matches
<javierm>
the problem is with simplefb, because fbdev has no knowledge about what DRM has done
<danvet>
yeah but imo 3) happening after 2) is a bug
<javierm>
so DRM will need to export a symbol for either fbdev or sysfb to query if there was a driver already registered
<danvet>
because the other way round the drm driver will have nuked the sysfb
<javierm>
danvet: yes, but problem is that sysfb is in drivers/firmware and that's linked by the kernel after drivers/gpu/drm
<danvet>
javierm, why can we set up the sysfb this late?
<javierm>
so if you have built-in the two, it's a problem
<danvet>
ffs
<javierm>
danvet: yeah...
<danvet>
javierm, I guess the correct fix would be to have a proper interface for kicking out the sysfb pdev
<danvet>
instead of the clever trick added in 27599aacbaefcbf2af7b06b0029459bbf682000d
<danvet>
and then call that from both fbdev and drm
<danvet>
and also in that function, set a flag to make sure the sysfb doesn't pop back up
<tzimmermann>
danvet, javierm, simply let fbdev export a hook and let drm aperture helpers fill its value whne the first driver acquires a range
<javierm>
danvet: can we use notifiers and a state in fbdev ?
<danvet>
well the entire aperture stuff still feels like a hack a bit
<tzimmermann>
after that fbdev will call into drm to drm
<danvet>
it's not very driver model at least
<danvet>
javierm, uh notifiers are nasty
<danvet>
just direct function call or something
Duke`` has joined #dri-devel
<tzimmermann>
danvet, because it is a hack
<javierm>
danvet, tzimmermann: also, the apertures infra wouldn't be needed if all the drivers requested their I/O mem resources
<tzimmermann>
how would we match generic devices to the real ones
<javierm>
so I think the correct solution here would be what tzimmermann proposed. To fix all DRM drivers to request_mem_region() and then sysfb would fail to do it
<javierm>
and not register the pdev in the first place if another driver grabbed that mem range
<danvet>
still feels silly since on anything modern the struct device already knows about all the ranges
<danvet>
both pci and of/dt at least
<danvet>
so the entire request_*_region stuff feels like busy work left around from isa days
<javierm>
danvet: hmm, right. Maybe then the core should handle it and not allow to register the device ?
<javierm>
that makes a lot of sense actually. I just wouldn't dare to fix this kernel wide :)
<danvet>
yeah I do feel a bit like our entire remove_conflicting_framebuffers dance is really something the driver core should be able to handle
<danvet>
at least the generic case
alanc has quit [Remote host closed the connection]
<danvet>
there's still special stuff like kicking vgacon
alanc has joined #dri-devel
<javierm>
demarchi: sorry, got distracted and now looked at your patch
<javierm>
demarchi: doesn't apply cleanly because drm-misc-next is still based on v5.16-rc5 and there are changes in include/linux/string_helpers.h landed in v5.17-rc1
<javierm>
I could easily resolve the merge conflict but my worry is that could cause issues down the road
<javierm>
probably better to wait until drm-misc-next is rebased on top of v5.17-rcx ?
alanc-away has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
alanc has quit [Read error: No route to host]
<karolherbst>
how are drivers generally dealing with phantom outputs? Like there is an output, but nothing is connected, because... stupid board layout or whatever. I see that for VGA you can't really rely on existing EDID, but is there some reliable way of knowing if there is actually a display on the other hand or do we have to report them as connected and hope that users won't mind?
<imirkin>
karolherbst: you do a load check, which is a hardware-specific thing
<imirkin>
to check if something's connected to VGA
<imirkin>
we do that. it's connected :)
<karolherbst>
yeah... I guess we are just out of luck here then
<karolherbst>
I just don't know very much about VGA era hardware and stuff :D
<imirkin>
we could drop support for pre-EDID
<imirkin>
i think EDID became a thing in the early-to-mid 90's
<karolherbst>
yeah.. I assume nobody has displays around like that anymore
<karolherbst>
we could add a flag
<imirkin>
presumably the folks who have a non-EDID monitor are kinda aware of that, and would be more likely to be aware that there's some special flag? dunno
<imirkin>
(or we could even print that info in the thing which disables it)
<karolherbst>
warning in dmesg might be helpful
<karolherbst>
"connected display with no EDID detected, boot with nouveau.no_edid_displays=1 to enable them"
<karolherbst>
but at this point more wondering about how other drivers deal with this
shankaru has left #dri-devel [#dri-devel]
tzimmermann has quit [Quit: Leaving]
<imirkin>
i think other drivers don't have improperly wired outputs
<imirkin>
it's really the best way to deal with it :)
<karolherbst>
:D
<imirkin>
nvidia was in a _lot_ of laptops, which aren't necessarily known for the best integration
<karolherbst>
so you mean for sure which ports are valid ones and we don't?
<karolherbst>
*they know
<karolherbst>
but yeah...
<imirkin>
as do we
<karolherbst>
although there were plenty of AMD laptops as well
<imirkin>
it's valid.
<imirkin>
we checked to see if something's connected
<imirkin>
it is connected.
<imirkin>
what more can we do?
<karolherbst>
ohh.. I was refering to some stupid vbios flag we don't care about
<imirkin>
it's on the dock i think
<imirkin>
we could somehow integrate to check if the dock is connected
<imirkin>
i haven't the faintest how one might do that
<karolherbst>
mhhhh
<karolherbst>
probabli some firmware interface or something
<imirkin>
not sure if the vbios indicates whether it's an output on the dock or not
<imirkin>
DCB specs are open, so we could double-cehck in tehre
<karolherbst>
would be interesting to know what nvidia does
<karolherbst>
right
<karolherbst>
like this? "0x18 = Mobile system with extra connectors on the dock"
<imirkin>
but ideally on the connector
<karolherbst>
it's in the connector table
<imirkin>
ok. well grab the vbios from that guy and see what it says?
<imirkin>
a lot of people reported those types of problems, esp around the time we added runpm
<karolherbst>
there is quite a bunch of stuff related to docks
<karolherbst>
0x50 = VGA 15-pin connector if not docked '(See Notes below)'
<karolherbst>
"There are some connector types, 0x50 through 0x57, that require extra code in the detection routines inside any code that uses the DCB. For Mobile systems, some connectors might only be on the actual body of the notebook. Also, some connectors might only show up on the docking station. Therefore we need to make sure that we don’t allow anyone to select a device that is not actually present. So, when we see connectors with the "if not
<karolherbst>
docked" and "if docked" text in the description, we must make sure that our detection code checks the docked condition first and possibly culls any further detection attempts if the docked condition is not met."
<karolherbst>
sooo.. mhh right
<karolherbst>
leaves us with the question: how to know if the laptops is docked or not
<MrCooper>
karolherbst: if the driver can't reliably detect whether or not something is connected, it should set connector_status_unknown
idr has joined #dri-devel
<imirkin>
MrCooper: it's pretty reliable. just some hardware is wired up funny.
<karolherbst>
MrCooper: the thing is... it looks connected
<imirkin>
OTOH
<imirkin>
we could start setting unknown for the docked-type ports
<MrCooper>
sounds like realiable as in unreliable :)
<karolherbst>
well.. we get not edid
<karolherbst>
but this is on VGA
<karolherbst>
so...
<imirkin>
MrCooper: well, it reliably works everywhere except these weird laptops
<karolherbst>
I guess no edid means unknown in 2022
<karolherbst>
but yeah...
<imirkin>
MrCooper: so do we set to unknown for everyone?
<karolherbst>
I think we should check if it's a docked connector
<MrCooper>
maybe set unknown for the smallest possible set which includes the unreliable connectors on those weird laptops
<karolherbst>
imirkin: it seems like that body connectors can vanish once the laptop is docked
<karolherbst>
and I am sure we don't do that either
<imirkin>
karolherbst: really? that'd be unusual
<karolherbst>
imirkin: read the text I was quoting
<imirkin>
huh, ok
<imirkin>
well, just coz an enum is there doesn't mean it ever happens
<karolherbst>
right
<karolherbst>
but those GPUS can't handle like 6 outputs
<karolherbst>
so if 2 are on the body and 4 on the dock...
<imirkin>
but they can handle 6 connectors :)
<karolherbst>
there might be some muxing happening, but yeah...
<imirkin>
fermi has 2 CRTC's
<karolherbst>
"if not docked" also sounds like a werid thing, but if it's like this....
<karolherbst>
hard to tell without having the hardware
<karolherbst>
imirkin: wow.. we don't even handle those ports inside nouveau
<karolherbst>
should go through fallback logic instead
<imirkin>
must not come up _too_ often
<karolherbst>
our fallback logic is quite good actually
<karolherbst>
the last time it broke was because of eDP
<karolherbst>
ehh
<karolherbst>
mDP
<karolherbst>
anyway... it was more of a userspace issue anyway
heat has joined #dri-devel
<jekstrand>
zmike: Looks like lower_precision is being called based on es_shader
<zmike>
yeah that sure is weird how es_shader is true for desktop GL
<jekstrand>
And it looks like es_shader is being set based on `version == 100`, glsl_parser_extras.cpp:478
<jekstrand>
"Shaders that specify #version 100 will be treated as targeting version 1.00 of the OpenGL ES Shading Language."
<jekstrand>
blarg
<imirkin>
jekstrand: pretty sure "#version 300 es" also sets es_shader
<jekstrand>
imirkin: Yeah, but we're looking at some GTF tests which are breaking in zink
<zmike>
is this even possible to fix
<jekstrand>
And they specify #version 100 for no good reason AFAICT.
<zmike>
regular cts changes take ages, and this is gtf
<imirkin>
jekstrand: GTF = "i'm sorry you have to deal with that" :)
<zmike>
the "good reason" is that these shaders are reused for the ES tests
<zmike>
but they don't use different #version directives
<zmike>
how do other drivers not trip this?
<jekstrand>
zmike: For the matrix ones, it may actually be zink bugs. I'd start there.
<alyssa>
jekstrand: i thought GTF was short for GTFO
<jekstrand>
zmike: AFAIK, the only drivers the GTF tests have been run against are radeonsi, iris, and i965.
<alyssa>
imirkin: ^
<jekstrand>
I don't think it's required for ES conformance anymore.
<zmike>
oh other drivers are hitting it
<zmike>
and it just doesn't affect them
<jekstrand>
:-/
<zmike>
cool
<jekstrand>
I'm still suspicious of zink bugs for the matrix test so I'd start there.
<alyssa>
jekstrand: I don't remember running any GTF tests on Panfrost and I got ES3.1 conformance ...
<zmike>
could be
ybogdano has joined #dri-devel
<HdkR>
Are precision qualifiers expected to work when using an ES shader in a desktop GL context? I've always wondered about this.
<jekstrand>
I think so, maybe?
<jekstrand>
They "they do nothing" is in the GLSL spec, not the GL spec.
<jekstrand>
And #version 100 very much says it's a GLSL ES shader.
<jekstrand>
But I don't think I'd have a problem with adding a bit to make mediump do nothing for all desktop contexts.
<imirkin>
jekstrand: it might be conflicting with GL_ARB_shading_language_100 or something?
<jekstrand>
But then someone would complain that there's different behavior between GL and GLES
<HdkR>
If you're mixing ES and GL like this, you're already asking for problems
<imirkin>
if you're running GTF, you're asking for problems :)
<HdkR>
The 1.0 GLSL spec didn't have a #version directive which is why this mixture works
<imirkin>
yeah, when you make the first of something, one tends not to think too hard about versioning
MajorBiscuit has quit [Ping timeout: 480 seconds]
<HdkR>
1.1 mandated that the version in the directive was >= 110 as well. Which is why you can assume 100 to be ES
<HdkR>
Such an abusive edge case
nchery has quit [Ping timeout: 480 seconds]
<HdkR>
Oh, also of course only works if your desktop version supports ES compatibility :)
<imirkin>
GL_ARB_ES2_compatibility is required as of some GL version
alyssa has left #dri-devel [🐠]
<imirkin>
GL 4.1, so pretty late :)
<HdkR>
Is this test expecting GL 4.1 minimum?
<graphitemaster>
TIL glBindBufferRange cannot be used with an indirect buffer, NV blindly accepted it and now I have an annoying bug to work around because my indirect params are not always stored at the base of the buffer
<graphitemaster>
Why the hell is it specified like that
<HdkR>
NV blindly accepts a bunch of things not allowed by spec. Always test on mesa instead :P
<graphitemaster>
It's because glBindBuffer is just glBindBufferNV and NV allows it in their spec.
<graphitemaster>
So is there a sane way to support this short of copying the buffer to a global dispatch indirect buffer
<graphitemaster>
I might just have to do that
<jekstrand>
danvet: Is git-cite part of the drm maintainer tools?
<imirkin>
graphitemaster: iirc you can give an offset, no?
<graphitemaster>
glDispatchComputeIndirect does not take an offset
<danvet>
jekstrand, there's a dim cite
<graphitemaster>
Oh
<imirkin>
oh, was thinking of draw
<graphitemaster>
Wait
<graphitemaster>
IT DOES
<graphitemaster>
I'm an idiot
<imirkin>
GLintptr indirect
<imirkin>
that might have something to do with it :)
<graphitemaster>
Yeah I thought that WAS the buffer object itself
<graphitemaster>
DSA has infected my brrain
<jekstrand>
danvet: Hrm... I've been using "git cite" and now it's gone and I don't know why
<graphitemaster>
Maybe it should've been named indirectOffset - gg Khronos
<imirkin>
graphitemaster: at least it's not a *indirect like the draw ones :)
<graphitemaster>
It's really confusing that the offset exists in the commands rather than the bind
<jekstrand>
Well, I know why. It's because I blew away my Intel install. But I don't know specifically why.
<imirkin>
because it's _so_ useful to dispatch *indirect* draws from *client* memory...
<graphitemaster>
But I guess it makes sense
<graphitemaster>
Binding should be avoided, so put the offsets in the command instead
<graphitemaster>
Useful for one unified buffer which is actually what I'm doing anyways.
<graphitemaster>
It's weird when you just have one buffer object bound to every single binding point
<graphitemaster>
Feels very anti-GL
<imirkin>
make sure you get the barriers right :)
<graphitemaster>
:D
<graphitemaster>
Old work code no-cap used `glMemoryBarrier(~0);` before every draw and dispatch command because no one could figure out the correct barriers and had to ship
<graphitemaster>
So I'm doing automatic barriers now
<graphitemaster>
Hopefully I get those correct
<imirkin>
you're doing glMemoryBarrier(~0) and you're thinking that it's the binding of the same buffer to all binding points which is anti-GL?
<airlied>
jekstrand: and llvmpipe (GTF tests)
<graphitemaster>
imirkin, :D
<graphitemaster>
I'm NOT. The code is because deadlines
<graphitemaster>
deadlines are also anti-GL
<graphitemaster>
fun fact
nchery has joined #dri-devel
Bennett has joined #dri-devel
<airlied>
jekstrand: sample shading and sample decoration on fs inputs in spir-v, got time to consult? :-)
<airlied>
ah zmike cc'ed you on the MR already
<zmike>
so...given that GTF tests aren't going to be changed before quantum computers make everything we've done obsolete, who would be opposed to adding a thing to mesa's glsl compiler to check the context version profile for non-es and then make #version 100 translate to #version 110?
<jekstrand>
airlied: Yeah, zmike's MR is definitely wrong
<zmike>
:(
<zmike>
so the decoration does need to be set on every variable explicitly?
<danvet>
jekstrand, ah maybe git config alias or something like that?
<airlied>
zmike: I've had GTF tests fixed before
<zmike>
yeah but this is like...every test
<airlied>
the question is though whether this is an actual bug in them
<zmike>
and also I think it's harder
<airlied>
have you built GTF correctly?
<zmike>
yep
<airlied>
since you have to pick GL or GLES at build time
<airlied>
and you get that wrong, things go horribly for you
<anholt>
airlied: thanks for filing the issue, I would have forgotten this morning. fix is up if you'd like to test before I toss it in for next release.
ahajda_ has quit []
mszyprow has quit [Ping timeout: 480 seconds]
<airlied>
zmike: can't you just change those tests that fail to highp?
<zmike>
maybe?
<zmike>
but the versioning is still illegal
<airlied>
actually changing to highp didn't seem to do much
<zmike>
doing my test run now, but at least the handling for it is simple
<airlied>
i think mareko might care, but maybe not
<zmike>
yeah I think that's likely to be the only other driver that supports it
<jenatali>
Damn, don't think I'm going to be able to make 4.0 before the branchpoint
<imirkin>
jenatali: more branchpoints in the future
<imirkin>
it's not the last chopper out saigon :)
<jenatali>
Yeah I know, I just thought I'd be able to make it
<imirkin>
jenatali: what's missing?
<jenatali>
fp64
<imirkin>
just hook up softfp - should take you 5 mins
<jenatali>
Which I think requires the full software lowering (we're missing too many things that don't have their own lowering), which then requires int64
<jenatali>
And 64bit varyings between stages, which is... not trivial for me
<imirkin>
and then you get GL 4.0, and no one will be the wiser (since no one uses fp64)
<imirkin>
hmmmm ... why not just split the varyings into 32-bit components?
<jenatali>
Yeah. It's a shame, we do have doubles, mul, div, fma, but we're missing things like rounding/floor/ceil which don't have dedicated lowering (yet)
<jenatali>
Yeah. That's the plan. I just need to do it
<imirkin>
right ok
<imirkin>
nothing hard, just a lot of typing
<jenatali>
Yup
ahajda_ has joined #dri-devel
<imirkin>
jenatali: "Notably, D3D doesn't support a single varying having components belonging to different streams, so we split up the variables to handle that." -- hm?
<imirkin>
how does that work in GL?
<imirkin>
oh, by default everything goes into every stream doesn't it...
<jenatali>
Mesa/st packs varyings together
<imirkin>
hehe
<jenatali>
And can pack varyings that are explicitly laid out for different streams into a single varying, turning the stream data into a bitfield
<imirkin>
and that packing is for the benefit of xfb, unfortunately
<imirkin>
you could make the stream thing be a "key" for the packing
<imirkin>
it won't pack some stuff together
<jenatali>
Yeah, I thought about changing mesa/st's behavior, but it was simple enough to just unpack it in the backend that I did that
<imirkin>
ah ok
<imirkin>
digging in the varying packing logic isn't always the most rewarding of tasks...
<imirkin>
the only reward you can be sure of is follow-on bugs to whatever you're trying to do :)
<jenatali>
Yeah
<jenatali>
sigh I need to get into a habit of building with gcc/clang more often, there's always warnings MSVC misses
<graphitemaster>
imirkin, HAH, glBindBufferRangeNV with offset in buffer for DISPATCH_INDIRECT_BUFFER and using constant 0 for glDispatchComputeIndirect on NV is quite a lot faster than specifying the offset to DCI
<imirkin>
no clue why that'd be the case
<graphitemaster>
Looking at the flame graph here, way less CPU time spent in the dispatch call when the offset is 0
<imirkin>
i believe you. i just have no clue why that'd matter
<graphitemaster>
Validation I guess
<graphitemaster>
I mean in the grand scheme of things it does not matter because I'm not limited by this at all in the slightest
<imirkin>
i would think that binding and rebinding would be the thing that's slower
<imirkin>
but what do i know
<graphitemaster>
The nvidia gods are performing miracles as usual.
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
<daniels>
emersion: done!
<emersion>
nice!
mszyprow has joined #dri-devel
gawin has joined #dri-devel
<airlied>
zmike: so changing that constbuf thing on llvmipe breaks those tests
<zmike>
airlied: weird
<zmike>
no effect on zink
<airlied>
zmike: fixes the matrix ones on zink here for me
<airlied>
zink on lavapipe
<zmike>
the matrix one is also fixed by avoiding lower_precision
<airlied>
yes, but I think that is just a big hammer fix without understanding what the problem is
<airlied>
I actually worked this out last year and have promptly forgotten it, I even talked to robclark about it
<airlied>
ah I only analyzed getuniform failing in 5477
<airlied>
I didn't dig into the others
<zmike>
I think that's still just a coincidental fix if I don't export the constbuf cap
<zmike>
the only reason it would fix anything is because the load can't be reduced to a 16bit value with lower_precision
<zmike>
but lower_precision is still being (incorrectly) run
gouchi has quit [Remote host closed the connection]
<airlied>
I think we have to ask that question in Khronos, I can't see anything in the specs
<zmike>
if you want to make an issue you could cc me? I'm afkish
mszyprow_ has joined #dri-devel
* airlied
is in with kids, so khronos gitlab is no chance :-P
<zmike>
I'll try and make one a bit later then
mszyprow has quit [Ping timeout: 480 seconds]
<Kayden>
hey, anyone know if there's a good way to do basic transfer queue testing with dEQP-VK?
<Kayden>
grepping the source code for VK_QUEUE_TRANSFER_BIT...it appears almost nowhere in their codebase, outside of some synchronization and VK_AMD_buffer_marker tests
<Kayden>
wasn't sure if there was some "run on queue <N>" option I was missing
haagch has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
ahajda_ has quit [Read error: Connection reset by peer]
mszyprow_ has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
cphealy has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
cphealy has joined #dri-devel
anujp has joined #dri-devel
pnowack has quit [Quit: pnowack]
Bennett has quit [Remote host closed the connection]
maxzor_ is now known as maxzor
<maxzor>
What does amdgpu stand for for you? Why is freedesktop in charge of the archives of a whole linux maintainer area?
<FLHerne>
maxzor: amdgpu is the kernel module for AMD GPUs
<FLHerne>
(from the last several years)
<maxzor>
FLHerne, that's what I recently updated on the wikipedia page, there was a link to an obscure xorg amdgpu driver.
<FLHerne>
Hm, did that exist? I assumed they just always used xorg-modesetting
<maxzor>
But I see a lot of discussions happening on dri-devel mailing lists, and AFAIK the development of amdgpu is at amd rock github
rasterman has quit [Quit: Gettin' stinky!]
<FLHerne>
pretty much all the vendor-specific DRI drivers are dead now, no-one needs to optimise 2D perf that much
<FLHerne>
maxzor: The amdgpu code is all upstreamed to the kernel; AMD might do their own development downstream but everything most users use goes through the kernel lists
<FLHerne>
for why freedesktop.org hosts the kernel graphics lists -- userspace and kernel graphics drivers have always been very closely coupled, it's often the same people working on both
<FLHerne>
less so now the vendors employ giant open-source teams, maybe
<FLHerne>
but it still makes sense to do it all in one place
<maxzor>
FLHerne, thank you!
<FLHerne>
Some of the kernel groups are looking at using freedesktop.org GitLab instead of mailing lists recently
<FLHerne>
not sure if thats actually happened yet for anything
rasterman has joined #dri-devel
<maxzor>
yea heard Vetter talking about it
<maxzor>
gitlab would not be bad. But freedesktop oO, I have nothing against them at all, I just don't find it super intuitive
LexSfX has quit []
<maxzor>
eh historic contingencies, does not matter
<FLHerne>
fd.o has Mesa, libdrm, Xorg, Wayland -- pretty much everything that actually interfaces directly with the kernel GPU drivers
<FLHerne>
[not a complete list]
rasterman has quit [Quit: Gettin' stinky!]
<FLHerne>
also has the CI farm across multiple companies with a couple of dozen types of GPU
<maxzor>
do you lend some timeslots? Debian buildd has no GPU and could surely use some for ROCm :D
<gawin>
anholt: (not sure if this kills basic idea of NIR but) recently I think it'd best to convert unsupported operations in NIR and then do NIR passes. (current form requires to duplicate even basic optimizations)
<gawin>
anholt: if we don't want to pollute nir just for older hardware, then we could: glsl_to_nir -> nir_to_tgsi -> rewrite instructions -> tgsi_to_nir -> passes -> nir_to_tgsi (such Frankenstein monster)
<gawin>
more overheaded on conversion, but we'd skip doing the same optimizations twice (and getting worse result)