<karolherbst>
it's triggered by b1bc691b0ff44e0acfb0ede759d4d1cf7636fca2 afaik
frieder has joined #dri-devel
<karolherbst>
I guess opt_algebraic needs to be more aware of the pack lowering options toggled
<karolherbst>
also doesn't help that we have skip_lower_packing_ops and all those lower_pack_* options
sima has joined #dri-devel
jfalempe has joined #dri-devel
<karolherbst>
I _think_ intel needs to get `.lower_pack_64_4x16 = true,` added
<karolherbst>
well.. will send an MR
<karolherbst>
but anyway, this packing situation ain't great and if somebody feels motivated enough to streamline things a bit, that would be awesome. Not sure I'm in the mood to dig into all the compilers this week
<karolherbst>
anywaya, MR opened
lynxeye has joined #dri-devel
<glehmann>
nir_lower_pack is also partially redundant with nir_lower_alu_width
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
CME has quit []
jlawryno has joined #dri-devel
bbhtt has quit [Quit: Bye!]
CME has joined #dri-devel
<jlawryno>
Hi, drm-tip has a merge conflit with drm-intel/topic/core-for-CI
<jlawryno>
anyone can help with this?
Plagman has quit [Remote host closed the connection]
bbhtt has joined #dri-devel
Plagman has joined #dri-devel
rasterman has joined #dri-devel
heat has joined #dri-devel
illwieckz__ has joined #dri-devel
chaos_princess has quit [Quit: chaos_princess]
illwieckz_ has quit [Ping timeout: 480 seconds]
chaos_princess has joined #dri-devel
jlawryno has quit [Quit: Leaving]
vliaskov has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<sima>
somehow missed this the first time around, and not entirely sure because monday morning
<sima>
but feels like it's the major piece we've been missing
fomys has joined #dri-devel
<tzimmermann>
sima, thanks for the pointer. i can't say i understand muh of the MM logic. but i'll take a look at the series. the cover letter makes it seem urgent
feaneron has joined #dri-devel
<sima>
tzimmermann, it's more long-term conversion towards folio/memdesc that the mm folks aim for
<sima>
but a side effect is that I think defio doesn't need struct page anymore to talk to core mm, so if we remove any remnants we have (like dirty bits I think we track in there still, so that'd need to be a bitmap and then I think we're done and could get rid of the phys_to_page from all defio code
<sima>
which means we don't need the bounce buffer for dma memory anymore, in case that's not struct page backed
<sima>
and so could undo your regression fix again and go for the nice unified world you had in mind
itoral has quit [Read error: Connection reset by peer]
rgallaispou1 has joined #dri-devel
rgallaispou2 has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
MrCooper_ has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
minecrell7 has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
MrCooper has quit [Read error: Connection reset by peer]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
<wens>
bbrezillon: I see in panthor_resume() atomic_read(), check, then atomic_set() if check passes; I wonder if it should be atomic_cmpxchg() instead?
guludo has joined #dri-devel
Hazematman has quit [Quit: WeeChat 4.5.1]
<tzimmermann>
sima, that sounds good. i was hoping for something like this to happen
JRepin has quit []
JRepin has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat_ has joined #dri-devel
Hazematman has joined #dri-devel
Hazematman has quit []
mvlad has joined #dri-devel
rcn-ee___ has quit []
vliaskov has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
pcercuei has joined #dri-devel
<bbrezillon>
wens: I guess we could turn that into an atomic_cmpxchg(), yes
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
Hazematman has joined #dri-devel
nerdopolis has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
amarsh04 has joined #dri-devel
itoral has quit [Remote host closed the connection]
<zmike>
anyone else have issues building piglit with recent python3?
fab has quit [Quit: fab]
<bl4ckb0ne>
is there somebody well-versed with VK and android AHB around? I'm getting `Gralloc4: non-BLOB pixel format with GPU_DATA_BUFFER usage is not supported prior to gralloc 4.1` and im pondering using BLOB pixel formats everywhere
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frieder has quit []
<Lynne>
can you not compile nouveau with nightly rustc?
frieder has joined #dri-devel
<Lynne>
""1.86.0-nightly" is not a valid Rust target, the patch version number must be an unsigned 64-bit integer"
fab has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
kzd has joined #dri-devel
hotmanhunter has joined #dri-devel
<hotmanhunter>
i gotta be honest, my brain is not enough to make it happen nor are my long working hours enough to succeed. Every day i get failures. I test this last algorithm i posted, and if the last power isn't incremented to higher number so that the two times distance is smaller than value and bigger than zero, it does not want to function correctly, so there are too many condtition and i am
<hotmanhunter>
falling with data probably still, since i have no time to continue this braindead research.
nerdopolis has joined #dri-devel
MrCooper_ is now known as MrCooper
amarsh04 has quit []
alyssa has joined #dri-devel
<alyssa>
nir_foreach_block blowing up in a null dereference in nir_cf_node_next because the exec_node_get_next is returning null .. but nir validation is clean .... this is scary (:
dviola has quit [Quit: WeeChat 4.5.1]
u-amarsh04 has joined #dri-devel
hotmanhunter has quit [Remote host closed the connection]
<alyssa>
ughh. I think this is another case of _safe not actually being safe
<alyssa>
*cry*
<zmike>
I've had that happen many times
i-garrison has quit []
<alyssa>
it is entirely too Monday for this
i-garrison has joined #dri-devel
<alyssa>
or rather, failng to use _safe
<alyssa>
bah
u-amarsh04 has quit [Remote host closed the connection]
Hazematman has quit [Quit: WeeChat 4.5.1]
bolson has joined #dri-devel
agd5f_ has quit [Remote host closed the connection]
rgallaispou1 has quit [Read error: Connection reset by peer]
davispuh has joined #dri-devel
agd5f has joined #dri-devel
Hazematman has joined #dri-devel
rgallaispou has joined #dri-devel
Hazematman has quit []
heat has joined #dri-devel
<markco>
I was working on implementing the NIR side of block matching from https://registry.khronos.org/vulkan/specs/latest/man/html/VK_QCOM_image_processing.html in Turnip and the SPIR-V instructions for them take two sampled images and coordinates which doesn't really work with `nir_tex_instr` only being designed for one instance of any `nir_tex_src`.
heat_ has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
<glehmann>
you can either add a new nir_tex_src for the second image, or you can use an intrinsic instead of a tex instr
<markco>
There's three solutions to this:
<markco>
* Add `2` variants (eg. `nir_tex_src_texture_deref2`) of the existing types.
<markco>
* Support multiple sources per type (perhaps only for this texop).
<markco>
* Make this an intrinsic instead and push most of the handling to the next layer (i.e. IR3 for Turnip), but there's still useful behavior within NIR for texops such as checking if handles are dynamically uniform for the divergence pass and that would need to be duplicated for the intrisic.
fomys has quit []
<karolherbst>
given the second image has semantics attached to it, naming the second one `deref2` might not be the best idea
<karolherbst>
sounds like it's more of a "reference" thing? so maybe call it `src_reference_deref` or so would be better
<markco>
glehmann: Yeah, I'm just thinking what the best option might be here and wanted opinions on it
kts has joined #dri-devel
<karolherbst>
the confusing part in the spirv ext is, why do you need to decorate images like this?
<karolherbst>
anyway.. I think if you add a second image src the name should be more explicit than 2
Duke`` has joined #dri-devel
<markco>
karolherbst: Essentially, the operation has a target and reference sampled images (+ coordinates) that the operation is run on. As far as tex srcs go, it should be `nir_tex_src_texture_deref`, `nir_tex_src_sampler_deref` and `nir_tex_src_coord` for each image.
<markco>
As for decorating it, I think that's more or less for validation purposes since this has a unique descriptor type (`VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM`)
<karolherbst>
I see
<karolherbst>
_maybe_ it makes sense to special case things here a little
<markco>
In what way, extra src type or support for multiple instances of a single src type?
<karolherbst>
probably the latter, given you not only have to add a texture reference, but a few more things
<glehmann>
markco: as long as you don't choose your third idea, I personally don't care too much. maybe ask the IR3 devs in #freedreno what they prefer
<karolherbst>
but I think it shouldn't just be "allow two of the same"
<karolherbst>
if you go that route
<glehmann>
multiple instances of a single src type is just weird and allowing it all common passes have to care about it to some degree
<karolherbst>
yeah... it's gonna be quite a lot of stuff to rework
<karolherbst>
but I think a lot of passes will need to care about it anyway if that's getting added
<karolherbst>
either by duplicating the deref -> index and coordinate lowering or whatever we have there, or by having some sort of loop
<karolherbst>
mhhhh
<karolherbst>
we could add an union to `nir_tex_instr`
<karolherbst>
it already contains a few op specific things
<karolherbst>
e.g. `tg4_offsets`
<karolherbst>
or is_gather_implicit_lod
<karolherbst>
and component apparently.. all tg4 stuff ...
<glehmann>
is_gather_implicit_lod is kind of gross and I would prefer to remove it at some point
<markco>
glehmann: I already talked to jnoorman (IR3 dev) and so far, and he was for the third idea so far but he has limited experience with the texop side of things
<karolherbst>
I think the issue here is, that it's going to touch a bit of code regardless of the solution
frieder has quit [Remote host closed the connection]
<karolherbst>
the issue with coordinate is, that there are tex operations which don't take one, so that's also a bit of fun...
<markco>
Yeah, the only solution which (probably) touches the least amount of NIR code would be making it an intrinsic and duplicating a lot of the texop logic for it
<karolherbst>
though... maybe splitting up the `src` field wouldn't be the worst idea...
<glehmann>
markco: the third idea is fundamentally incompatible with nir_tex_instr_src_index
<karolherbst>
I think we should go for a mix of 2 and 3
<markco>
Yeah, and it would need to be modified for it
<karolherbst>
question is just, what should the result look like
<alyssa>
i'm inclined to nak #3 for the reason glehmann says
<markco>
karolherbst: So a src2 of sorts with `nir_tex_instr_src2_index`?
<karolherbst>
I think we should have two arrays of sources, one for the "target" and the other for the "reference"
<alyssa>
please no.
<karolherbst>
every solution will suck, I can already see 2 being ugly enough
<karolherbst>
basically means duplicating a lot of stuff and checking "is this 1 or 2?
<markco>
Yep, this is really about which one sucks the least so that it's acceptable upstream..
<alyssa>
yes, which is why glehmann and I are asking you to pick a solution that sucks for ir3 instead of a solution that sucks for everyone including ir3
<karolherbst>
do we anticipate others wanting something similar long-term?
<jenatali>
Going from 2 derefs to 3 doesn't seem like a big deal to me?
<jenatali>
There's already texture and sampler. Adding a reference or whatever it's called seems fine
<alyssa>
I think that's my preference yeah
<karolherbst>
the second pair can also be texture+sampler thing
<glehmann>
tex source types are cheap, so I would just add nir_tex_src_ref_coord and similar for all the things you need
<alyssa>
new src types for reference_image_deref or whatever
<alyssa>
^ yeah
<karolherbst>
yeah.. we can go for that for now, I just think the end result will also look bad enough that we consider doing it a bit differently
<karolherbst>
but ...
<karolherbst>
it would touch the same parts of the code
<markco>
Right, that theoretically works. I can handle most of the questionable bits within IR3.
<alyssa>
+1
<karolherbst>
I'm sure it's also fair to add a bit of lowering to nir passes if that's not too ugly
<glehmann>
what does this look like in hw? does adreno have actual instructions that take multiple descriptors?
<markco>
Yep, it does
<markco>
It's more or less identical to the SPIR-V instruction
<glehmann>
that's quite a lot of fixed function for 2025 :D
<karolherbst>
well it's just two additional registers I guess
<karolherbst>
for an op not really taking any else
<jenatali>
Unrelated question: Our video folks are wanting to get a build environment that's gallium without nir for (e.g.) libva. Looks like that needs a meson option to turn off adding libnir to the build. Would folks be amenable to that?
<alyssa>
I really don't know why that assertion would fail but only on windows/msvc
<jenatali>
alyssa: Looking
<alyssa>
thanks
<jenatali>
I've got a hunch...
<karolherbst>
jenatali: va doesn't seem to use any nir code, right?
<jenatali>
karolherbst: Right
<jenatali>
But right now just building gallium pulls in nir, and requires an actual definition of (at least) nir_print_shader
<alyssa>
it seems.. questionable but I don't care (:
<karolherbst>
well.. cleaning up the linking aspect of the build system isn't necessarily a bad idea :D
<karolherbst>
I've done a bit of that last year or so
<jenatali>
There's stuff in gallium/aux that assumes it's there
<karolherbst>
rely on the linker to be smart enough?
<karolherbst>
drivers will pull in nir already anyway, so I don't think a frontend which doesn't use nir should do it
<alyssa>
jenatali: umm
<alyssa>
vl_compositor
<alyssa>
va depends on nir
<jenatali>
This is a little less about binary size and more about build times... and also the fact that we've got security policies that are applying static analysis requirements to everything we build :(
<jenatali>
alyssa: We've got a currently downstream frontend that doesn't use that but also plugs into the gallium interface
<karolherbst>
I mean..... getting static analysis on nir wouldn't be the worst idea
<karolherbst>
probably
<jenatali>
Heh, it requires a bunch of build warnings enabled, some of which are... really dumb
<karolherbst>
I think my take is that it depends on the patches and how it looks like
<alyssa>
you know what. i am too exhausted to care. go wild y'all
<karolherbst>
jenatali: as in "a complete disaster to fix"?
<jenatali>
:P
<alyssa>
a-b's for everyone, yippee!
<jenatali>
As in there's nothing wrong with the code, so the "fix" is just applying dumb changes that make the code harder to read to silence dumb warnings
<karolherbst>
mhhhh
<karolherbst>
if I'd have to take a guess, around VLAs?
<jenatali>
That's one of 'em
<karolherbst>
does this "this field is the length of this VLA" feature would fix some of that?
<karolherbst>
because I do kinda think we should use those new attributes anywya
<jenatali>
In C++ "flexible array entries" are technically undefined behavior and MSVC has a warning that says that using them is a vendor extension
<karolherbst>
mhhhh
<jenatali>
So just including nir.h triggers that warning since it uses those for things like nir_src for intrinsics
* karolherbst
makes head scratching noises
<jenatali>
alyssa: Does bindgen write files opened in binary mode or text mode?
<jenatali>
I'm failing to quickly find where the source for that ended up
<jenatali>
Ah yeah there it is, fopen(outhfile, "w")
<jenatali>
Make that "wb" and you should be good
<alyssa>
jenatali: ...Okay
<karolherbst>
jenatali: I think I want to see the patches and how terrible this all will be :D
<alyssa>
thanks, I think heh
<jenatali>
I saw this with spirv-as.exe in the past, text mode messes with binary code to convert line endings
<alyssa>
amazing
<jenatali>
karolherbst: Yeah it's not *too* bad
<karolherbst>
different line endings were a mistake
<radiosumnrnone>
the procedure kind of works, but requires a division by 4 the least so far (though all members of a bank yield deterministic), in other words the delta is only going increase to the point i no longer can handle it very easy, and 24/5 is 3 same as 12/4 is 3, you know i can not seem to land the hack, it's over my budget mission, but the filesystem is likely possible. so 141+3 is 144/2 is
<radiosumnrnone>
72 is the only last red indian standing , so the dependency chain i posted, is only working algorithm so far for data compression, but needs larger base address calculated, but the vaue shifts too much away, i did not find a better way. So technology world is somewhat horribly difficult and such things i seem not be capable of pushing through from. Dog makes sure i could not connect no
<radiosumnrnone>
one in this world, he is some nutbolt trashbag.
anholt has joined #dri-devel
greenjustin has joined #dri-devel
fab has quit [Remote host closed the connection]
coldfeet has joined #dri-devel
radiosumnrnone has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
pjakobsson has joined #dri-devel
<DemiMarie>
jenatali: Consider yourself lucky you are not using GLib. That will happily call functions with too few arguments, too many arguments, or with arguments with wrong pointer types. Oh, and it expects that to work.
<ricomandale>
it's 24/8=3 of course, anyhow the procedure needs more work, but that is the start of longer journey, as i did get 4 cells all to work so.
<ricomandale>
i am getting awesomly tired, and it shows how this point of interest delta is shifting away.
ryanneph has joined #dri-devel
dumbbell has quit [Quit: WeeChat 4.4.3]
dumbbell has joined #dri-devel
dumbbell has quit []
dumbbell has joined #dri-devel
kts has quit [Quit: Leaving]
agd5f_ has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
fab has joined #dri-devel
dsimic is now known as Guest7934
dsimic has joined #dri-devel
Guest7934 has quit [Ping timeout: 480 seconds]
ricomandale has quit [Remote host closed the connection]
agd5f has quit [Ping timeout: 480 seconds]
palderianokitty has joined #dri-devel
<alyssa>
aaaand the ppc64 and s390x builds failed..... cool..
alanc has quit [Remote host closed the connection]
<alyssa>
these builds passed a few days
<alyssa>
something llvm 15->19 related..
<glehmann>
does s390x still have users? (not saying we should remove support for it, just curious)
<alyssa>
apparently yes
alanc has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
<alyssa>
it wasn't the LLVM uprev, since these jobs passed on Friday and that was already merged last week
<alyssa>
oh.. meson.build change in 82047fa82f1 ("amd: drop support for LLVM 15, 16, 17")
<alyssa>
umm.
<alyssa>
ok.
<alyssa>
even worse, s390x and ppc64le are failing in different ways?!
<alyssa>
s390x is missing spirv-tools but ppc64el is getting the wrong version of llvmspirvlib
Hazematman has quit [Quit: WeeChat 4.5.1]
<karolherbst>
... "fun"
<alyssa>
karolherbst: did you land something to break this
<alyssa>
seemingly no
<karolherbst>
I don't think so.. well I bumped the spirv-tools version, but I don't see why that would break things this way
<alyssa>
right..
<alyssa>
meson.build:1883:21: ERROR: Dependency lookup for LLVMSPIRVLib with method 'pkgconfig' failed: Invalid version, need 'LLVMSPIRVLib' ['< 15.1'] found '19.1.0.0'.
<alyssa>
this raises so many questions I don't know how to answer
<karolherbst>
mhhhhhhh
<karolherbst>
maybe a hardcoded 15 somewhere?
<karolherbst>
".gitlab-ci/container/build-libclc.sh:LLVM_TAG="llvmorg-15.0.7"" doesn't look great tbh
<alyssa>
yeah, idk why s390x and ppc64le is special though
<karolherbst>
`&debian-ppc64el-llvm 15`
<karolherbst>
`debian/ppc64el_build`
<karolherbst>
`LLVM_VERSION: &debian-ppc64el-llvm 15 # no LLVM packages for PPC`
<karolherbst>
I guess that would do it
<alyssa>
so that explains half of this, I guess
<alyssa>
maybe my Friday pipeline wasn't rebased enough to get the llvm bump
<palderianokitty>
but the filtering out from the sums procedure works, and addressing is hence possible, so if someone could make a better connection than i did? dudes it's not easy for you either, it takes a lot of time, so why the fuck are you harassing me? I post now the other cells of set, so 888+120=1008 32+1024-1008=48 892+124=1016 32+1024-1016=40 and you do the swisslandord procedure yourself,
<palderianokitty>
and you see they work the same. so 12 or 24 for first 16 or 32 for the second and third set. first was 883-768=115 1024-883-115=26, so the rule is 115-26-26 has to be smaller than the value 72, but bigger than zero same as 120-48-48=24 same as 124-40-40=44, those conditions have to hold. and remember the hash had two times the mate 69+69=138+138 + 66+66=132+132 64+64=128+128, so the
<palderianokitty>
computer stores those values in memory of a word. and 115+768=883 120+768=888 124+768=892 part gets generated on fly to access data., so the filesystem encodes things so and to the formula you enter the distances like shown by arrigopapito or swisslandlord. I am getting tired, if i come to xdc i search for people right away to bat them or beat up, you better wish i won't come.
<alyssa>
Unfortunately this is where my understanding of CI ends
<alyssa>
so I think I have to tap out now. alas
agd5f has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
Hazematman has joined #dri-devel
<DemiMarie>
glehmann: I susoecto
<DemiMarie>
Ooops
<DemiMarie>
Typo
<DemiMarie>
I doubt any of the accelerated drivers are used on mainframes.
<Lynne>
airlied: I'm seeing issues with av1 decoding on radv
<Lynne>
something looks like it goes wrong with the refs
palderianokitty has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
Calandracas has joined #dri-devel
denery has joined #dri-devel
haaninjo has joined #dri-devel
grammyawardwin has joined #dri-devel
<linyaa>
qq. is anyone working on new uapi that requests a drm commit at a user-provided target present time?
<linyaa>
context: i'm investigating the progress of VK_EXT_present_timing.
<linyaa>
and Android hwcomposer apis.
jkrzyszt has quit [Ping timeout: 480 seconds]
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
BesterGester83962 has quit []
BesterGester83962 has joined #dri-devel
<emersion>
linyaa: iirc we figured the compositor should be able to make it work without KMS additions
gouchi has joined #dri-devel
illwieckz__ has quit [Remote host closed the connection]
gouchi has quit [Quit: Quitte]
kzd has quit [Quit: kzd]
BesterGester83962 is now known as BesterGester
iive has joined #dri-devel
<grammyawardwin>
DemiMarie: Do whatever it takes, just don't susoecto! Hell this sounded like one of my nicks! Anyways from that spot forwards you end up doing a bit of arithmetic on the 138+138, so you add and remove the values 141 that was 1024-883 and play back and forth until you get to the point where against one operads diff, you get to single 3. from where i had failed so far to get to
<grammyawardwin>
112+72+115+144=443 as to get to -256-115=72 , which seems like a failure, but encoding could account with twice the data value , which indeed sucks quite bad, where i need to work a bit more.
rasterman has quit [Quit: Gettin' stinky!]
<zamundaaa[m]>
emersion: with VRR, scheduling with the CPU is unfortunately not good enough. For that, we do want some API
<zamundaaa[m]>
For FRR it should indeed not be needed though
kzd has joined #dri-devel
grammyawardwin has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
<linyaa>
i agree with zamundaaa
camaro_owner has joined #dri-devel
denery has quit []
yrlf has quit [Ping timeout: 480 seconds]
yrlf has joined #dri-devel
<emersion>
ah yeah
<sima>
linyaa, emersion I think we had some endless bikeshed on that vk discussion but I guess adding a target frame timestamp prop for atomic flips is probably the way to go
<sima>
there's a bit of pain on the backend since currently scheduled flips for FRR aren't even exposed through atomic either
<emersion>
I agree
<emersion>
with "not before" semantics probably
<sima>
so might be a bit a mess from an uapi pov if you can get target ts through atomic but target frame through legacy only
<sima>
but then probably not the worst we've done
mvlad has quit [Remote host closed the connection]
ddavenport has joined #dri-devel
<linyaa>
another uapi piece that VK_EXT_present_timing wants is a feedback timestamp that indicates either (a) when the display controller began scanning out of the framebuffer memory or (b) when the first pixel becomes visible. (i assume that [a] is easier on most hw).
<emersion>
we already have that
<linyaa>
oh good
<linyaa>
what is the api bit that i can grep for?
jsa1 has quit [Ping timeout: 480 seconds]
ryanneph has quit [Ping timeout: 480 seconds]
ryanneph has joined #dri-devel
<camaro_owner>
138+138+141+141-512=46 and +26=72 138+138-72=204-144=60+12=72 that has been my approach so far, but to get to single 3+141=144 from 12 is thqt wingle buffer is maintained. so 138+141+132-256=23+132 now *2 is 46+132+132 now +26 is so 138+138+132+132-72-132-132+12 is 216+112+115=443-256-115=72 .... oooh jesus how tired i am, can somebody help with controlling any of this for sanity-
<emersion>
struct drm_event_vblank
<sima>
yeah vblank events should be really precise and correct for first pixel going out through the connector, as much as the hw can do
<sima>
so not taking sink latency into account if it's external
<sima>
*corrected for first pixel
<emersion>
yup
<sima>
unfortunately we don't have uapi that tells you how much it's been corrected or whether it's just a timestamp grabbed in the irq handler :-/
<sima>
but would be fairly easy to add that somewhere
<sima>
could even expose the resolution of the clock we use for correcting (iirc it's either pixel clock, line counter or some hw timestamp with a sub-usec resolution)
<jannau>
the apple firmware based display controller very likely needs frame timestamps for VRR. don't have to be user space generated but it would of course easier
<sima>
jannau, currently VRR is "asap"
<sima>
but that has really bad amounts of jitter since you go through an entire fairly big syscall and async work to get there
<sima>
maybe even more depending upon hw
camaro_owner has quit [Ping timeout: 480 seconds]
camaro_owner has joined #dri-devel
<jannau>
"asap" is unfortunately not quite asap with apple's FW (at least with the way we currently use). if my understanding is correct a swap takes 1-2 ms
Duke`` has quit [Ping timeout: 480 seconds]
<sima>
yeah with fw there's probably a bit more latency on top that all adds up
illwieckz has joined #dri-devel
fab has quit [Quit: fab]
Hazematman has quit [Quit: WeeChat 4.5.1]
Hazematman has joined #dri-devel
<zamundaaa[m]>
Knowing that latency would also be very important for userspace, with or without a scheduling API
<linyaa>
For precise timing info (requests and feedback), I think it's also important to specify which clock timeline these timestamps occur on. IMO, precise timing info is more important than trying to shove everything onto the same CLOCK_MONOTONIC timeline.
<linyaa>
VK_EXT_present_timing supports having different timing events occuring on different timelines. For example, CLOCK_MONOTONIC vs the display controller's (perhaps different) clock timeline. VK has functions to map time values from different clocks onto a unified timeline (such as CLOCK_MONOTONIC).
<linyaa>
We don't want the upstream KMS api to make VR users vomit, yknow :-) Precision prevents vomit.
<linyaa>
(disclaimer. i'm a vulkan person, not a kms person. i may say uninformed things regarding kms).
feaneron has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
<camaro_owner>
well it seems 115-12=103 138-103=35-26=9 is needed for the unknown 112, so let me try that once i come up from sleep again.
zsoltiv__ has quit [Ping timeout: 480 seconds]
camaro_owner has quit [Ping timeout: 480 seconds]
any1 has quit [Ping timeout: 480 seconds]
haaninjo has quit [Quit: Ex-Chat]
camaro_owner has joined #dri-devel
camaro_owner has quit [Remote host closed the connection]