heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
blue__penquin has joined #dri-devel
<jekstrand>
Corbin: I'm not sure if that's awesome or just plain wrong.
<alyssa>
yes
blue__penquin has quit []
Corbin has quit [Ping timeout: 480 seconds]
SanchayanM has joined #dri-devel
heat_ has joined #dri-devel
danvet has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
blue__penquin has joined #dri-devel
heat_ has quit []
heat_ has joined #dri-devel
heat_ has left #dri-devel [#dri-devel]
heat has joined #dri-devel
bcarvalho_ has quit []
bcarvalho has joined #dri-devel
bcarvalho has quit []
aravind has joined #dri-devel
jvesely has joined #dri-devel
bcarvalho has joined #dri-devel
pascal has joined #dri-devel
pascal has quit []
pnowack has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
jvesely has quit []
aiddamse has joined #dri-devel
aravind has quit [Remote host closed the connection]
pzanoni has quit [Ping timeout: 480 seconds]
<pq>
alyssa, that may have been another me. Every 15 mins I make a non-identical copy of myself and overwrite the old instance, so I'm not sure what any past me did.
blue__penquin has quit []
blue__penquin has joined #dri-devel
<pq>
cphealy, I have a vague recollection there might be kernel command line options to force a user supplied EDID and force a connector to be "connected".
<pq>
cphealy, for the latter, look for the video mode setting on kernel command line.
uzi has joined #dri-devel
<pq>
btw. this talk about Vulkan over-synchronization that people want to solve; could it cause a game to run at 40 fps on a 60 Hz display if it was otherwise perfectly capable of 60+ fps? Just curious in general.
<pq>
or is the over-sync hit only visible when fps exceeds display rate?
<Kayden>
as danvet said in his email... it does seem pretty lame to continue supporting relocations on those platforms just because igt hasn't gotten updated, when all the actual drivers have stopped using the interface
<Kayden>
I mean...it's probably not a big deal to have them, since other gen12 parts already have them, so it's not like we could actually save any real complexity by turning them off, as far as I can tell
<Kayden>
but, yeah, seems like igt just needs to get fixed. I have no idea how much work that really is
<dt9>
Kayden: o lot of unfortunately, that's why try to defer this point of time to release the pressure
<dt9>
we got to fix ~900 subtests
<Kayden>
ugh :(
<Kayden>
yeah that's a pain
<pq>
Would be nice if Gitlab had a "search for all MRs touching paths...".
<pendingchaos>
it used to give a https://tracie.freedesktop.org link that I could use to look at the before/after images and hashes, but that seems to be gone now?
Viciouss has quit [Ping timeout: 480 seconds]
_whitelogger has joined #dri-devel
_whitelogger has joined #dri-devel
_whitelogger has joined #dri-devel
_whitelogger has joined #dri-devel
<mripard>
/window 14
<dt9>
airlied: I'm not sure was it "formal" or just ack with talk to danvet
_whitelogger has joined #dri-devel
Viciouss has joined #dri-devel
blue_penquin has joined #dri-devel
illwieckz has quit []
illwieckz has joined #dri-devel
pcercuei has joined #dri-devel
mslusarz has quit [Quit: leaving]
mslusarz has joined #dri-devel
pcercuei has quit [Quit: brb]
paul has joined #dri-devel
paul is now known as Guest4838
Guest4838 has left #dri-devel [#dri-devel]
pcercuei has joined #dri-devel
pcercuei has quit []
mlankhorst has joined #dri-devel
pcercuei has joined #dri-devel
pcercuei has quit []
pcercuei has joined #dri-devel
<Venemo>
idr: do you have any further comments on the NIR commits in MR 3151? we're planning to merge it this week.
<danvet>
airlied, dt9 the one you did ack is for removing relocations, this one re-adds them for adl because igt isn't ready (media is now)
<danvet>
just clarify
<pendingchaos>
where can I find the reference images for the radeonsi-stoney-traces:amd64 job?
Lightkey has quit [Ping timeout: 480 seconds]
jnd has joined #dri-devel
<danvet>
Lyude, [PATCH v7 04/10] drm: Introduce the DP AUX bus <- did you see this one?
Lightkey has joined #dri-devel
<jnd>
Hey! A software-illiterate needing a hand! I'm searching for a way to use Zink on my Windows 10 operating system. After hours of searching my last hope lies here. I've only found releases for Linux and some forks for Windows but haven't got the slightest clue on how to try it on my computer!
<jnd>
BTW so much nostalgia using irc after 15+ years! Oh the good old times
<zmike>
zink isn't currently supported on Windows
<kusma>
Hmm, winsys support for Windows *did* land, didn't it? It's not going to be fast, because of the CPU copying of the framebuffer, but depending on the workload, that might still be useful...
Danct12 has quit [Remote host closed the connection]
<jnd>
That's what I found as well but I'm clueless on how to get it working on my pc
Danct12 has joined #dri-devel
<kusma>
I haven't tried it myself, but I would imagine it works the same as what we used to do for the D3D12 driver, where you need to build opengl32.dll (or an ICD, but there's some hairy bits there), and drop it next to your application exe.
<kusma>
Or, well. Some other place that will take presedence over the normal OpenGL32.DLL. But next to the exe is usually a great place to stuff it.
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
aissen is now known as magistrHAL
yann-kaelig has joined #dri-devel
<pinchartl>
hverkuil: would you be opposed to a patch changing the limits of the VIVID_CID_INTEGER64 control in vivid ? right now they're [INT64_MIN, INT64_MAX] which makes it impossible to test from userspace that setting an out-of-bound value will result in the control value being adjusted
<pinchartl>
in theory it could result in a breakage in some userspace applications, but that's very very unlikely
magistrHAL is now known as aissen
vsyrjala has joined #dri-devel
<jekstrand>
airlied: How close are we to conformance on lavapipe?
macromorgan has quit [Quit: Leaving]
macromorgan has joined #dri-devel
<bnieuwenhuizen>
zmike: ^
<zmike>
I'm not super up to date, but iirc there's a semi-hacky branch for 1.1 conformance
<zmike>
and 1.2 is ???
<zmike>
I'm planning to get back to some lavapipe stuff later this week once I finish some other things
_whitelogger has joined #dri-devel
<cphealy>
pq: thanks for the info. I did find the EDID override code in the kernel. Now I just need to figure out if this works with the vendor BSP... :-(
<Lyude>
danvet: yep
rsripada has quit [Remote host closed the connection]
rsripada has joined #dri-devel
emersion has quit [Remote host closed the connection]
emersion has joined #dri-devel
xp4ns3 has joined #dri-devel
Guest4778 is now known as dcbaker
bl4ckb0ne has quit [Quit: Death is but a door, time is but a window, I'll be back!]
bl4ckb0ne has joined #dri-devel
macromorgan has quit []
macromorgan has joined #dri-devel
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
markyacoub has joined #dri-devel
rsripada has quit [Remote host closed the connection]
anujp has quit [Quit: WeeChat 3.0.1]
anujp has joined #dri-devel
rsripada has joined #dri-devel
anujp has quit []
anujp has joined #dri-devel
<jekstrand>
danvet: I'm afraid I'm missing something with kernel mailing list conventions. What am I supposed to do with get_maintainers.pl?
<imirkin>
imo, nothing
<imirkin>
it's there for when you have no clue who to send stuff to
anujp has quit []
<imirkin>
presumably you're working in an area where you know the mailing lists / people involved
anujp has joined #dri-devel
<danvet>
jekstrand, find the address of everyone to cc on dma-resv/buf stuff
<danvet>
people you know you can omit
<danvet>
the thing tells you also why it adds someone, so any because of drm subsystem you can also omit
<imirkin>
that script does a lot of things which i think are a bad idea... like telling people who don't know better to include random occasional contributors
alanc has quit [Remote host closed the connection]
lynxeye has quit []
alanc has joined #dri-devel
<danvet>
it should only do that if it doesn't find a clear maintainer
<jani>
it could be turned into a useful tool to use with git send-email --cc-cmd
<xp4ns3>
imirkin, if you want (and you should) to exclude occasional contributors run it the following way...
<jani>
...but that means bikeshedding on some perl script changes
<anholt>
airlied: deqp hates llvmpipe's GLES points and lines, are you sure your changes aren't just better? :)
<alyssa>
jekstrand: anholt: Was there a gitlab issue (or IRC discussion maybe) about nir_validate times in CI?
<alyssa>
I could've sworn we discussed this but I'm drawing a blank
<airlied>
anholt: my problem is I've no idea what standard llvmpipe is currently implementing, or even what I should change to make it do the right thing
<jekstrand>
alyssa: I made it massively better several months ago
<airlied>
I've mostly hacked it into submission without a clear understanding of what the correct answer looks like
<alyssa>
jekstrand: so I'm not losing my mind, good
<anholt>
alyssa: nothing in recent memory
<jekstrand>
alyssa: On Intel, NIR_VALIDATE=0 makes a debug run 50% faster.
<jekstrand>
alyssa: As opposed to 7x faster like it used to
<alyssa>
jekstrand: Someone should port lavapipe to the macOS just to see it on the M1
<alyssa>
and claim "fastest non-layered Vulkan driver for Macs"
<alyssa>
:p
* zmike
looks at some alyssa one
<alyssa>
zmike: excuse me i have a gallium driver to finish first
<alyssa>
and a kernel driver to write
<zmike>
uh huh
<jekstrand>
excuses excuses
<jekstrand>
danvet: Q about the amdgpu over-reporting
<jekstrand>
danvet: Is it really going to blow up? If it ends up in another driver, it'll get attach() and do its thing. If it ends up in a CPU wait, that should cause something somewhere to happen, I'd expect. Or is poll() broken?
<alyssa>
jekstrand: :V
<bnieuwenhuizen>
jekstrand: if poll waits on the exclusive fence that is broken I think?
<danvet>
jekstrand, poll is broken, but anytime you try to act on that you get caught
uzi has quit [Read error: Connection reset by peer]
<danvet>
I think
<danvet>
the real trouble starts when we'd add proper explicit management of implicit fences to amdgpu with opt-out
<danvet>
latest then you _have_ to set the explicit fence for everyone I think
<danvet>
since at that point the mandatory checkpoints are gone
* jekstrand
waits for sphinx to build kernel docs....
<jekstrand>
airlied: My deqp run says lots of copy-and-blit tests are failing
<danvet>
incremental is much faster
<danvet>
usually at least
<jekstrand>
Yeah. I re-pulled drm-tip recently. It takes a while if you've done a big pull
* jekstrand
misses working on a small code-base like Mesa. (-:
<airlied>
I'll do a run against main once I'm prepared to listen to fan noise for an hour
<jekstrand>
airlied: Yup. Fixes it.
<jekstrand>
airlied: Running again with those.
<jekstrand>
airlied: I'm nowhere near the machine's fan so I don't mind. :)
<jekstrand>
2000 miles away or so, in fact.
* jekstrand
needs something to do while he waits on kerneldoc
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
uzi has joined #dri-devel
<jekstrand>
Wow, lavapipe really doesn't like vertex shaders that don't use the input VBs....
<airlied>
oh I should remove that draw printf
<jekstrand>
And people complain about ANV's one or two printfs. :-P
<alyssa>
lol
<alyssa>
jekstrand: I'm kinda peeved I don't have Linux on my M1 yet
<alyssa>
since I want to use it to build kernels for the M1
<alyssa>
turtles.
<jekstrand>
alyssa: If what you really care about is building things, you can use a VM
<alyssa>
Yeah, I could. It's funny this way, though
<airlied>
can't xcode builds linux kernels? seems like a good waste of time :-P
<alyssa>
airlied: last I checked linux doesn't build on case insensitive
* jekstrand
shakes his fist at DOS for popularizing case-insensitive filesystems
<airlied>
alyssa: guess you know where to start then :-P
* jekstrand
can't wait to see the LKML discussion when alyssa sends patches for building Linux on case-insensitive filesystems.
<alyssa>
airlied: hush
<alyssa>
jekstrand: sorry, I like not getting SIGKILL threats
<jenatali>
NTFS supports per-directory case sensitivity these days in order to handle WSL :)
<airlied>
I'd try building on my mbp but it's currently doing crocus, and I probably don't have enough disk space on OSX partition to even install xcode
<idr>
jekstrand: You mean CP/M? ;)
<jekstrand>
jenatali: That may be the only think I can think of *worse* than a case-insensitive file-system. (-:
<alyssa>
jekstrand: what about per-file case sensitivity?
<jenatali>
D:
<jekstrand>
alyssa: I don't see how that would be well-defined.
<jekstrand>
jenatali: Can you have a case-insensitive directory inside a case-sensitive one?
<airlied>
jekstrand: so is there a long boring story about why vulkan lines aren't GLES lines, or was it just nobody cared enough to notice?
<jenatali>
jekstrand: Yep
<alyssa>
jekstrand: that's the joke
<jekstrand>
/o\
<jekstrand>
airlied: There is a long boring story and I don't remember all of it
<alyssa>
is that an issue for hardware?
<alyssa>
^ hardware drivers
<jekstrand>
alyssa: Generally, we made it more like D3D
<jekstrand>
So that's usually ok for most folks
<jekstrand>
But with other misc. differences.
<alyssa>
I more mean should one expect a .line_type = VULKAN | OPENGL bit somewhere
<jekstrand>
airlied: What exactly are you seeing? I can probably provide an explanation for any given thing.
<airlied>
jekstrand: look at the test results from dEQP-VK.rasterization.interpolation.projected.non_strict_lines,Fail or one of those
<jekstrand>
k
<airlied>
but there are also some GLES2 deqp line fails that I'm pondering
<airlied>
I'm unsure if we are just calculating interpolation slightly wrong somewhere there
* jekstrand
wonders is his lavapipe run or kerneldoc will finish first
<jekstrand>
airlied: Oh, interpolation is a mess
<airlied>
my hack for vulkan is to always draw start and end points which seems to make it happy
<jekstrand>
But we should make lavapipe have the nvidia behavior since we can control it.
<airlied>
ideally I'd like to have the llvmpipe be able to support vulkan strict lines + GLES2 lines which I assume enables VK_EXT_line_rasterization
<jekstrand>
Yeah, it should all be supportable
<jekstrand>
Just need to sort out details
<airlied>
or maybe I don't care about vk strict lines
<alyssa>
i'm still trying to figure out if M1 supports wide lines
<airlied>
dEQP-GLES2.functional.rasterization.interpolation.basic.lines_wide is the other side of the coin
<alyssa>
Metal doesn't but I guess I can try to trace the GL-on-Metal blob and see what awful hack they d
uzi has quit [Ping timeout: 480 seconds]
<alyssa>
do
<jekstrand>
Geometry shader?
<alyssa>
Metal doens't support those
<airlied>
I don't get why vulkan requires llvmpipe to draw first/last points always though even after reading the spec
<alyssa>
I should also trace the GL-on_metal blob for those :p
<airlied>
then I got into maybe it's CTS requirements that aren't in the spec, then I went and wrote crocus instead
<imirkin>
path of least resistance? :)
<jekstrand>
:-/
<alyssa>
how's crocus these days?
<jekstrand>
When in doubt, go work on a less-functional driver where the bugs are easier.
<alyssa>
jekstrand: good idea
* imirkin
expecting an influx of nouveau contributions
<airlied>
alyssa: if you don't have sandybridge it's great, otherwise you have sandybridge
<jekstrand>
<insert joke about jekstrand working on i915 here>
<airlied>
oh look sunrise, time to go for a walk and not think about lines
<jekstrand>
lol
<alyssa>
airlied: you know how to not think about graphics when you go for walks? teach me
uzi has joined #dri-devel
<bnieuwenhuizen>
alyssa: have more pressing and horrible issues
<bnieuwenhuizen>
on the non gfx side
<alyssa>
ah
<jekstrand>
Hrm... lvapipe's pow() doesn't work
<dcbaker>
start a dozen non-graphics related projects and don't finish them
<dcbaker>
that works for me everytime
<imirkin>
jekstrand: "doesn't work"?
<jekstrand>
imirkin: Has the wrong behavior around inf