illwieckz_ has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
Duke`` has joined #dri-devel
glennk has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
mbrost has joined #dri-devel
<benjaminl>
does vulkan spirv specify the behavior of out-of-range int->float conversions?
rz has quit [Remote host closed the connection]
rz has joined #dri-devel
<benjaminl>
my reading of the spec is that it should be inf with RTNE and the max finite value with RTZ, but it's weird that there's no CTS tests for this case
<HdkR>
More tests for the tests gods
blaztinn has quit [Remote host closed the connection]
<benjaminl>
hahaha yeah
<benjaminl>
unless I'm missing something here :)
blaztinn has joined #dri-devel
dt9 has quit [Remote host closed the connection]
kxkamil has quit [Remote host closed the connection]
dt9 has joined #dri-devel
kxkamil has joined #dri-devel
<benjaminl>
ah, GL_EXT_shader_explicit_arithmetic_types explicitly says that out-of-range int->float is undefined
<benjaminl>
I was second-guessing because panfrost currently does int32->float16 by truncating to int16 first, but I think that behavior is legal in opengl and illegal in vulkan
lesliearrowdeed has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
kugel has quit [Remote host closed the connection]
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
mbrost has joined #dri-devel
kugel has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jsa1 has joined #dri-devel
anarsoul has quit [Ping timeout: 480 seconds]
<glehmann>
benjaminl: yes it's illegal in VK. I don't think it's legal in GL either if you have a highp int to mediump float conversion?
<glehmann>
at least for i32 -> fp16 it has to be illegal because FLT16_MAX is larger than INT16_MAX, even without overflow you will get incorrect results
jsa2 has joined #dri-devel
gnuiyl_ has quit []
gnuiyl has joined #dri-devel
jkrzyszt has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
vliaskov_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<benjaminl>
yeah, sorry, meant illegal for u16->fp16. i16 is always illegal. I'm not sure about mediump, but I'm replace this with i/u16->f32->f16 regardless
<benjaminl>
*replacing
vliaskov__ has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
anarsoul has joined #dri-devel
Karyon has joined #dri-devel
vliaskov__ has quit [Remote host closed the connection]
vliaskov__ has joined #dri-devel
fab has joined #dri-devel
fab has quit [Quit: fab]
u-amarsh04 has quit []
<sima>
mripard, I guess another case of "atomic is hard"
<sima>
might be better we chat here to figure out what to do
<mripard>
the plus side is you never stop learning I guess :D
<sima>
it's great
<mripard>
so let's ignore my series for now, and focus on what the problem is. For his work on error recovery, Herve needs to access and power-cycle the CRTC onwards. So you need to get access to the current CRTC that feeds that bridge.
<mripard>
for now, he's been following the drm_encoder->crtc pointer, which isn't great.
<mripard>
I guess the issue I'm trying to solve is how a bridge can access the CRTC outside of the modesetting code path
<mripard>
(and without relying on !atomic, legacy, pointers)
u-amarsh04 has joined #dri-devel
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
raminkhonsari has joined #dri-devel
kts has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
Shibe has quit [Remote host closed the connection]
raminkhonsari has quit [Remote host closed the connection]
ramin has joined #dri-devel
lesliearrowdeed has joined #dri-devel
fab has joined #dri-devel
Company has joined #dri-devel
fab has quit [Quit: fab]
kts has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
devarsh_ has joined #dri-devel
luc has quit [Read error: Connection reset by peer]
devarsh_ has quit []
devarsh_ has joined #dri-devel
<lesliearrowdeed>
My own tests based of shorter sequences to make data accesses, have all failed in fact, but they have not followed sensible logic either.
<lesliearrowdeed>
so the depchain i posted was the only stable way, there is one more, but it has huge compile delay, as well as storage inefficiency
pcercuei has joined #dri-devel
<sima>
mripard, ok that's a different thing, and I guess for that we should push the locking into a bridge specific helper
<sima>
LOCK_ALL works, but it's also overkill
<sima>
essentially you need mode_config.connection_mutex, which stabilizes the connector states enough that you can walk them
<sima>
that gives you the crtc, and then you can just use the existing helper (or at least is in-flight, I put an ack on it)
<sima>
so you do not need LOCK_ALL at all
<sima>
but it's tricky enough that we should have a bridge helper for this
<sima>
also if you make the bridge routing more flexible, you need to walk bridge states and that means grabbing the locks for those as you walk them
<sima>
until you hit the encoder, which is stable, then you grab mode_config.connection_mutex so you can read-only walk connector states (without adding them to your drm_atomic_state ideally, so this is a bit tricky and defo should not be done in drivers)
<sima>
and that gives you the crtc you want to call drm_atomic_helper_reset_crtc
<sima>
unless I missed something
<sima>
I guess the read-only walking of connnector states to find the crtc or connector for an encoder is something we should perhaps extract from atomic helpers
<sima>
so that relevant other helpers can use it
<sima>
but maybe not export it to drivers or something like that, if doable
luc has joined #dri-devel
<sima>
mripard, hm I redid all the loops in atomic helpers to just walk connectors, so we don't yet have the code to go from encoder to its connector I think
<sima>
ah no, I think steal_encoder() has what you want
heat has joined #dri-devel
<sima>
mripard, also to your fundamental question of how can a bridge access the crtc outside of the modesetting path: not, but you can do a full modeset if your in a threaded context
<sima>
which is what your reset example ends up doing
<sima>
this is also why legacy cursor hack and to a lesser extent, the async flip stuff is such a mess: it tries to bypass the modeset machinery
fab has joined #dri-devel
<lesliearrowdeed>
Lot's of the code has just aged a bit for modern usage APIs and ABIs too. Once i showed boyi slides about every opencl method. Such terms as locking memory did not serve already then, but it serves even fewer with compression enabled, but i am hopefully landing the last tests and maybe get my hands on developing something. There is bit hysteria about war getting close to areas here, i
<lesliearrowdeed>
do not have enough experience on detecting or destroying attack drones, i know there isn't any more powerful method known on the web than is antimatter controlled annihilation, and cameras also i know nothing about, i know there just cubious amounts of energies released in neutrino energy field particle collisions, Europe deals with such technologies, i am not worth scientist in those
<lesliearrowdeed>
subjects. if the underlying compute system works fast, the energy can form light too.
nerdopolis has joined #dri-devel
<mripard>
sima: except you don't have access to the global state after swap_state, so you can't make that walk, even with all the right locks?
<sima>
mripard, you do a full atomic commit
<mripard>
right, but you need to identify the CRTC to do the commit on using the existing state
<sima>
nope
<mripard>
how can you go from drm_bridge to drm_crtc then without drm_atomic_state?
<sima>
I thought you could reuse the code from steal_encoder, but that relies on add_affected_connectors having been called already
<sima>
which we cannot rely on here since we start with the bridge
<sima>
which I guess is why you think we can't at all, but we still can by stealing the essential part of the add_affected_connectors logic
<sima>
so big flow is 1. bridge -> encoder (currently easy, but in a dynamic future only needs bridge locks to get at bridge state)
<sima>
2. encoder -> connector, using a combo of the tricks add_affected_connectors and steal_encoder uses
<sima>
3. connector -> crtc
<sima>
4. reset crtc using an atomic commit
<sima>
my apologies for designing this stuff :-/
<mripard>
oh, yeah, that makes sense
<mripard>
thanks :)
<sima>
I thought you could extract the magic encoder -> connector trip, but for existing users it's split up so unfortuantely we need a new one
<sima>
but I think a drm_atomic_connector_for_encoder() core function would be good, even just to document this trick
<mripard>
ack, I'll work on it
<sima>
and then maybe also a drm_bridge_find_encoder, to handle the legacy/fixed bridge chain vs dynamic case using atomic states and modeset_lock correctly
<sima>
they both need at least a drm_modeset_acquire_ctx, I think you can avoid the drm_atomic_state for both
<sima>
so maybe just drm_connector_for_encoder(struct drm_modeset_acquire_ctx *ctx, encoder)
<sima>
and similar prototype for the bridge part
<sima>
I think with that approach you could even directly reuse the existing drm_atomic_helper_reset_crtc
<sima>
since you don't need the atomic state yet to walk the pointers, it's all read-only
<sima>
if you do it right at least
<sima>
you only need the right locks, for which acquire_ctx is enough
<sima>
and then a nice drm_atomic_helper_reset_bridge that ties it neatly together
<sima>
oh also please kerneldoc links between the variants and maybe even some DOC overview comment about how to link reset different stuff?
<lesliearrowdeed>
last time i hear germans talking about atoms sequences or nucleotides in case of monomers and such, but isotopes definition more related to extra energy rich methods is still nuclear , it's the particles inside the atom, proton and electron, and phosphor though having equal amounts of those, it forms anion as told in web in reaction terms it is used in battery as negative contact. but
<lesliearrowdeed>
plus alklalines we have too a lot. Really it's all that i can comment there, i know cern and austrial mainstream science already tests in real products some of the most efficient nuclear technologies, for me such things ain't gonna happen locally fast enough.
<lesliearrowdeed>
allotropes are named for atomic sequences.
<mripard>
sima: I'll do my best :)
kts has joined #dri-devel
<sima>
mripard, ping me if you're stuck
<mripard>
sima: the code is fine, but I'm sure the locking and doc is going to suck :)
igtr has joined #dri-devel
epoch101 has quit []
Daanct12 has quit [Quit: WeeChat 4.5.1]
jsa2 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
cascardo has quit [Remote host closed the connection]
pcercuei has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
cascardo has joined #dri-devel
pcercuei has joined #dri-devel
ramin has quit []
lesliearrowdeed has quit [Remote host closed the connection]
f_ is now known as funderscore
cascardo has quit []
stinkstobeme has joined #dri-devel
cascardo has joined #dri-devel
kugel is now known as Guest9628
kugel has joined #dri-devel
Guest9628 has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
kugel has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kugel has joined #dri-devel
<stinkstobeme>
so all that is getting very complex 69+69 was 138 so if that was first bank and first index presumably you call the 256-230=26 and 256-115=141, next base on every index has to be smaller or bigger? 141-138=3 and run the procedure, i'd go for starting with preallocated bigger bases to encourage every one to be careful or think upfront. But the calculations are just so annoying.
<stinkstobeme>
256-57-57-57=85 128-85+26+3=72 etc etc , so do we allocate 256digits worth storage for every 138 alike and leave it possibly to half the occupancy cause everything depends on what the max values are so 120 it was 70-66 pair for 115 72-69 naturally or do we account the maximum like 141 and 136 etc. i'd go for the last but instead of increasing indexes i'd choose decreasing ones similar to
<stinkstobeme>
bases, i think that helps to account with the future by will?
cascardo has quit [Ping timeout: 480 seconds]
cascardo has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
stinkstobeme has quit [Remote host closed the connection]
bolson has quit [Ping timeout: 480 seconds]
thinblueline has joined #dri-devel
<thinblueline>
filesystem at child's shoes. I could still make the testing go fast enough, but whatever I do not know what standing in thin blue line means except that i am a known color blue guy. I assume none wants to work, first operation on this type of storage facility is to write a loop that accounts the real format for execution capable things. and take notes of 32 and 64 bit storage capability,
<thinblueline>
i am nobody in mathematics world, i can not calculate so big numbers in the head. Though the first thing before that is a set of people willing to allow modern features to be allowed in then the technical implementation to follow.
jsa1 has quit [Ping timeout: 480 seconds]
thinblueline has quit [Remote host closed the connection]
jsa1 has joined #dri-devel
bolson has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
kugel has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
sally has quit [Quit: sally]
kugel has joined #dri-devel
epoch101 has joined #dri-devel
kzd has joined #dri-devel
kzd_ has joined #dri-devel
<stsquad>
is there a minimum version of the vulkan api required for venus to work?
kzd has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
phasta_ has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
<digetx>
venus only requires presence of certain vk extensions, otherwise it doesn't have min vk version, afaik
fab has quit [Quit: fab]
Fijxu_ has joined #dri-devel
jsa1 has joined #dri-devel
Surkow|laptop has joined #dri-devel
mripard has quit [Quit: WeeChat 4.5.1]
<stsquad>
digetx: but failure of those extensions causes virglrenderer to return with a fail?
<stsquad>
or should QEMU probe itself?
<stsquad>
digetx: see CAFEAcA_TJhgrcfZ-9JY74OvkiGXPuYHJF16=_3Y+=r6+JfXMGA@mail.gmail.com (nvidia prop driver crashes)
<stsquad>
we could just blacklist nVidia
Duke`` has joined #dri-devel
anholt has joined #dri-devel
sally has joined #dri-devel
<austriancoder>
alyssa: is asahi's gallium driver the best when looking for a transform feedback implementation for hw/sw that does not support it natively? panfrost has one too..
<alyssa>
sigh
nylonbeatfan has joined #dri-devel
<alyssa>
if you're just trying to pass gles3.1 cts, use panfrost's
<alyssa>
panfrost's is not valid for desktop gl or gles3.2, but you do not want to go there.
<alyssa>
adult-level transform feedback is just a special case of geometry shaders
<alyssa>
at some point I expect panfrost to switch over to the adult-level version, but that will come with emulated geometry shaders
<alyssa>
which is... not what you want if you're asking me this right now ;)
<alyssa>
(writing common code for "geom/tess/XFB/pipeline-stats/primitive-restart/indirect-draws emulation" is .. happening, very slowly. but yeah.)
<alyssa>
you can't pick off just one of those problems and emulate it correctly without considering the interactions with the other 5
<alyssa>
I /think/ this is finally all correct (though not always efficient) in honeykrisp
<alyssa>
and that ate up, like, over a year of my time lol
<nylonbeatfan>
yep, actually to do anything related to superior performance than fixed at strategy of vendors, many things have to be emulated. interactions are known.
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
<nylonbeatfan>
it is possible, but indeed that is known, but i have not even started , especially what is unknown is the reactions as well as allowance to do anything among the lines i had queued up.
<mlankhorst>
I mean drm-misc-fixes was sent out earlier today :)
<sima>
oh
<sima>
does it need to be this fast?
<mlankhorst>
nah
<mlankhorst>
otherwise it'll be ready for next, that's fine too
<sima>
I guess I could smash it into drm-fixes directly, but doesn't feel like that's needed
<sima>
mlankhorst, btw 2x add in your commit message
<sima>
s/add add/add/
nylonbeatfan has quit [Remote host closed the connection]
aligometershand has joined #dri-devel
<mlankhorst>
Ah right
heat has quit [Read error: Connection reset by peer]
<mlankhorst>
Will push it to drm-misc-fixes and fixup before I forget. :-)
heat has joined #dri-devel
<digetx>
stsquad: nv driver is known to not work with venus, don't use it for testing
heat is now known as Guest9640
Guest9640 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<stsquad>
digetx: this was someone else running into the bug when running QEMU's functional tests. So we need to defend users against using it on their systems
<stsquad>
digetx: btw I got vulkaninfo on the working image and confirmed it doesn't have VK_KHR_display either - so I think the easiest approach will be to patch vkmark not to *require* it
<digetx>
heard nv fixed some of issues in their beta driver, in general don't think it's our problem
tzimmermann has quit [Quit: Leaving]
rz_ has joined #dri-devel
rz has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
davispuh has joined #dri-devel
<austriancoder>
alyssa: good to know - not sure if I need/want the adult-level one for zink.
<daniels>
austriancoder: etnavk?
Kayden has joined #dri-devel
<austriancoder>
daniels: there might be a branch named that way in my mesa repo, but atm I am dealing with a closed vulkan driver
Kayden has quit [Remote host closed the connection]
<DemiMarie>
austriancoder: which one?
Kayden has joined #dri-devel
<austriancoder>
DemiMarie: can't tell
<DemiMarie>
austriancoder: is this on some sort of embedded system where you don't know the driver?
<austriancoder>
DemiMarie: can't tell
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
chewitt has quit [Quit: Zzz..]
<alyssa>
austriancoder: ...wait, this is for zink?
<alyssa>
dear lord
<alyssa>
well, uh
<alyssa>
good luck
chewitt has joined #dri-devel
<alyssa>
(in general it seems to be easier to do these sorts of heroics efficiently in a hw driver where you have extra knobs to play with, versus in a pure layered impl)
<zmike>
at that point might be easier to just implement in mesa/st
<alyssa>
(although that might just be my "I work on hw drivers and get lost whenever I touch zink" bias)
<alyssa>
(any common code I write for emulation intends to support layered impls, so it's not impossible obviously.)
<alyssa>
s/it's not/I don't think it's/
heat has quit [Read error: Connection reset by peer]
<austriancoder>
I can't touch the driver at all - my current workaround: MESA_GLES_VERSION_OVERRIDE
heat has joined #dri-devel
<alyssa>
this is the prop vivante vk?
<austriancoder>
no
<alyssa>
..care to share with the class then?
<daniels>
alyssa: just keep guessing
<alyssa>
well, I think Arm caved and did xfb in their prop vk driver
<austriancoder>
NDAs .. sorry
<alyssa>
hm why am i guessing let me check gpuinfo
<zmike>
it could be a secret driver that has never been reported
<austriancoder>
lets change topic before I get into troubles
<alyssa>
zmike: Apple??????
<zmike>
!
<austriancoder>
how's your weather today?
<zmike>
apple-y
<Kayden>
magical
<DemiMarie>
austriancoder: Companies like Collabora might be willing to do consulting under an NDA.
jsa1 has quit [Ping timeout: 480 seconds]
<alyssa>
based on gpuinfo i guess it's IMG or something, it's just, we have open src vk drivers for all vendors except Viv (and, like, Huawei and Samsung I guess...?) in tree now
phasta_ has joined #dri-devel
<alyssa>
and i assume all of the mobile things are ANGLE-y and not Zink-y anyway
apinheiro has joined #dri-devel
<daniels>
austriancoder: sales@collabora.com if you need help :)
<austriancoder>
daniels: :)
<alyssa>
...at any rate, if the underlying vk driver does geometry or tessellation shaders, but not XFB... yeah you're screwed.
phasta_ has quit []
<alyssa>
(it *might* be possible to bolt something onto HW GS's, but you need /something/ to deal with the prefix sum requirements which like. these are all solvable problems but I don't think anyone has solved them either. And I highly don't think zink, or mesa/st, is the right place for this.)
<pac85>
is Huawei and Samsubg's version of mali different enough to not be able to be supported in panfrost?
<alyssa>
pac85: Samsung is a version of AMD afaik
<alyssa>
IDK what Huawei is doing
<alyssa>
(does Huawei even make gpu's? i know they have VK_HUAWEI extensions)
<pac85>
I thought it was mali for Huawei
<alyssa>
iirc there was also an IMG spinoff, Moores Thread maybe?
<HdkR>
alyssa: Exynos 2100 from 2021 was Mali, but 2200 and 2400 is Radeon. With the latest devices they may have switched entirely over to Snapdragon although.
<pac85>
ah so rip amd on mobile?
<pac85>
sad
<alyssa>
HdkR: entertaining
<HdkR>
At the very least this year's phone didn't have an Exynos variant, which has been taken by some to mean that Exynos is dead.
aligometershand has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest9644
dsimic has joined #dri-devel
Guest9644 has quit [Ping timeout: 480 seconds]
aligometershand has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
<austriancoder>
daniels: would you be really unhappy if I would assign !3418 to marge? Atm I have no idea how to proceed.
sarnex has joined #dri-devel
chewitt has quit [Quit: Zzz..]
<Lynne>
validation layer has been lying to me all day chasing a bug that doesn't exist
<Lynne>
my code runs fine on lavapipe and nvidia's proprietary drivers but miscompiles on nvk, radv and anv
<Lynne>
glslang takes 30 seconds to compile my simple shader which just happens to do a few BDA accesses
<Lynne>
maybe it's time we give up on this vulkan stuff
<alyssa>
Lynne: what's the alternative
<alyssa>
opengl?
<alyssa>
nap time?
<alyssa>
i vote nap time
<Lynne>
let's have lisp machines for GPUs
<Lynne>
no one's tried it before
<Lynne>
maybe we can run 20000 emacs instances at once, if emacs crashes, at least some of them should continue
<Lynne>
(yes, my emacs crashes too, we're really good at this computer malarkey)
iive has joined #dri-devel
<mlankhorst>
Feed your LLM directly into 20k instances of emacs. :-)
<soreau>
Lynne: would it make any sense to use spir-v so the nonworking cases work?
<Lynne>
two wrongs to make a right? hmm, perhaps, but I think that behaviour got broken by a recent glslang version
<Lynne>
ah, maybe the reason why spirv has silly little foibles like not being able to run bitwise ops on non-32bit types is because it was designed for high-level interpreted languages, right, that explains it.
<aligometershand>
I would want to move away from all vulkan/glsl/directx but such a mess in head , can not really get over the line with data manipulation in compressed. I do not know if i see only hallucinations still.
jkrzyszt has quit [Quit: Konversation terminated!]
mbrost has joined #dri-devel
<gfxstrand>
Okay, It's been too long since I've done GL.
<zmike>
welcome back
<Lynne>
oh yeah also zink segfaults here (but not under gdb, so I don't even know where)
<gfxstrand>
dcbaker: How do I make a piglit test show up twice with different args? It's been a loooooonnnng time
<alyssa>
gfxstrand: i often forget i ever stopped doing GL
<alyssa>
apparently my platform has vk1.4 now but idk how that happened, apparently you wrote me a vulkan driver?
<alyssa>
whatever, cool, thanks for the driver i guess
<alyssa>
=)
<gfxstrand>
Ya'know. Just for shits and giggles, I might rewrite the Vulkan common synchronization code again...
<alyssa>
Go crazy, girl :)
<gfxstrand>
That happened a long time ago. :-P
<alyssa>
so true
<gfxstrand>
The fact that I'm considering touching that code is proof of this.
funderscore is now known as Guest9651
<alyssa>
gfxstrand: i mean i've been sending kernel patches by choice, so I get it (((:
Guest9651 is now known as funderscore
Piraty_ has quit []
Piraty has joined #dri-devel
<dcbaker>
gfxstrand: put the same binary into the profile twice with different argumetns?
fab has quit [Quit: fab]
<gfxstrand>
dcbaker: Where are the profiles?
* gfxstrand
feels like a total noob
<dcbaker>
Nah, I just way over-engineered that stuff :D
<dcbaker>
in $piglit/tests/ there's a bunch of .py files, that at build time get interpreted and converted to xml files
<dcbaker>
those are the profile sources
<dcbaker>
If you look through there, y'll see a bunch of with profile.test_list.group_manager(... calls, those give you a function you pass a string list to that is the binary and any arguments you want to pass to the binary
<dcbaker>
the very end of opengl.py has an example of adding arguments
rasterman has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<gfxstrand>
How does iris pass my new piglit test?!?
<zmike>
test too weak
<gfxstrand>
My attempt at kicking off a submit thread didn't work
<zmike>
does iris even do threaded submit
<gfxstrand>
IDK but ANV does and that's what I'm trying to force
<zmike>
ah
<gfxstrand>
Because things get a lot more annoying when the Vulkan driver has a submit thread
gouchi has joined #dri-devel
igtr has quit [Remote host closed the connection]
<gfxstrand>
Okay, now iris/ANV fails
<gfxstrand>
Zink is still good
lynxeye has quit [Quit: Leaving.]
CME has quit []
CME has joined #dri-devel
gouchi has quit [Quit: Quitte]
rcf has quit [Quit: WeeChat 4.4.4]
rcf has joined #dri-devel
rcf has quit []
sima has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
rcf has joined #dri-devel
<zmike>
🤝
britt2011 has joined #dri-devel
unerlige has left #dri-devel [#dri-devel]
<gfxstrand>
It wrecks ANV+Iris, though. :)
<jenatali>
Now you've got me curious
<gfxstrand>
jenatali: dozen should be okay
<jenatali>
Yeah WDDM doesn't need submit threads, but that doesn't sate my curiosity!
<gfxstrand>
To be clear, it's also broken with Zink but I have an MR to fix it.
<gfxstrand>
Just need final signoff from zmike for that one
<HdkR>
zmike: "Mesa's generic Zink OpenGL-on-Vulkan driver" Suddenly Zink is the Dr. Thunder of video drivers :D
<zmike>
I what
<zmike>
gfxstrand: so it's done now?
<gfxstrand>
Yup
<gfxstrand>
I think the test is in good shape too
<zmike>
good shit
<zmike>
HdkR: TIL Dr. Thunder
<HdkR>
zmike: I love me a generic cola.
<HdkR>
The Mr. Pibb of mesa drivers maybe better? :P
<zmike>
I don't really drink soda so it's all lost on me
<HdkR>
Tis a shame
britt2011 has quit []
jsa1 has quit [Ping timeout: 480 seconds]
kylp has joined #dri-devel
kylp has quit []
kylp has joined #dri-devel
sguddati has joined #dri-devel
kylp has quit [Remote host closed the connection]
kylp has joined #dri-devel
nerdopolis has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
kylp has quit [Ping timeout: 480 seconds]
guludo has quit [Quit: WeeChat 4.5.1]
Duke`` has quit [Ping timeout: 480 seconds]
kylp has joined #dri-devel
kylp_ has joined #dri-devel
kylp_ has quit [Remote host closed the connection]
kylp_ has joined #dri-devel
kylp has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
kylp_ has quit [Remote host closed the connection]
kylp_ has joined #dri-devel
kylp_ has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
rasterman has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
dakr has joined #dri-devel
danilo has quit [Read error: Connection reset by peer]
* DemiMarie
hopes for userspace fences now that a way to implement them is known
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
<gfxstrand>
So say we all
<gfxstrand>
Who's claiming to know how to implement them this time?
<DemiMarie>
I thought you, Christian, and Sima figured out a way to do it
<DemiMarie>
Or at least a way to allow long-running compute and Vulkan winsys to coexist in the same context
<DemiMarie>
Is the consensus still that all the complexity needed for dynamic memory management is worthwhile, as opposed to "just" pinning everything?