<jenatali>
Invocation 0 writes different patch data compared to the other invocations, which violates: "Tessellation control shaders will get undefined results if one invocation reads a per-vertex or per-patch attribute written by another invocation at any point during the same phase, or if two invocations attempt to write different values to the same per-patch output in a single phase."
<jenatali>
imirkin: Looks like you're the author
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<HdkR>
Probably one of those things where it is undefined but games rely on it to be a certain behaviour? :D
<jenatali>
In which case... what's the tribal knowledge on the right behavior? Which invocation wins?
<jenatali>
I started by implementing 0, but invocation 0 puts the wrong answer for this test, so I guess it's not that... probably last? Or truly undefined and this test is just bogus?
<jenatali>
That's not quite relevant. That's about the per-vertex/control-point data, I'm interested in the patch data
<jenatali>
Barrer-patch test, not barrier test
camus1 has joined #dri-devel
txenoo has quit [Quit: Leaving]
camus has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: Neato!
<jenatali>
Oh I see what's wrong. I need to loop in the patch constant phase and run it for each invocation ID for each section between barriers. Fun
<jekstrand>
jenatali: I don't see what's wrong with that test. It does a bunch of writes, then a barrier, then a bunch of reads.
sdutt_ has quit [Read error: Connection reset by peer]
<jenatali>
jekstrand: in the second phase, instance 0 will read sequential indices and will miss the branch, so by the end of the loop it hasn't written a new color
<jenatali>
jekstrand: any good way to wrap an existing block in a loop in nir? Or should I just add the loop in the backing writer?
<jenatali>
Oh I guess I can just wrap the block, since I need to end the loop and restart it on barriers
<jenatali>
Oh well. The test is fine, I'll be able to make it work
<jekstrand>
jenatali: Not seeing it yet. It seems to walk the whole of val[] and one of them is bound to be non-zero.
<jenatali>
Not non-zero. It compares the value at index to index itself, not zero
<jekstrand>
Right. Ok, I see it now.
pcercuei has quit [Quit: dodo]
<jekstrand>
So how does it work in any other driver?!?
<jekstrand>
jenatali: Take a look at nir_control_flow.h
<jenatali>
Thanks, will do
<jekstrand>
jenatali: You can call nir_cf_extract(), insert a loop and whatever flow you need, and then nir_cf_insert()
<jenatali>
jekstrand: I think I've talked myself into having to copy instructions one-by-one so that I can split the block (end the loop and restart it) at barriers
<jekstrand>
jenatali: Nan, nir_cf_extract takes two cursors that can be at arbitrary instructions. You're not the first one to think of doing this sort of op. :)
<jenatali>
Oh cool
<jekstrand>
I'm still confused as to how this is expected to work
<jenatali>
Yeah, I think this is a test bug but does happen to work on existing drivers
* jekstrand
is very confused how
<jenatali>
I think it's a distinction between invocations writing different values after the barrier, vs some invocations writing and others not
lemonzest has quit [Quit: WeeChat 3.3]
* jekstrand
is so very confused
<jenatali>
jekstrand: Is there a way to get the predecessor block that's not in control flow? I'm not sure how to tell if a current instruction's block is in a loop/if or if it's just after one
<jenatali>
I.e. I need to insert a loop that'll be terminated by a barrier, and a barrier can't be in control flow, so I need the most immediate dominating block that's not in control flow, I think
eukara has joined #dri-devel
<jekstrand>
you can cf_node->parent lets you walk up the tree
<jekstrand>
Then cf_node_as_block(cf_node_prev(cf_node->parent))
<jenatali>
Is there a simple check for if a current block is in control flow? I'm not sure how to distinguish between a block that's in control flow vs one that just follows one
<jenatali>
Maybe I'm not just not grokking the cf nodes though, I haven't had to go in-depth here yet :)
<DrNick>
understanding R600 read ports is cursed knowledge
Duke`` has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
<mareko>
luckily GCN came about with a clean ISA and I didn't have to learn the r600 ISA craziness
gouchi has joined #dri-devel
gouchi has quit []
robertfoss has quit [Ping timeout: 480 seconds]
robertfoss has joined #dri-devel
rasterman has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
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
tursulin has joined #dri-devel
mvlad has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
pcercuei has joined #dri-devel
pnowack has joined #dri-devel
tango_ is now known as Guest10209
tango_ has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
MajorBiscuit has joined #dri-devel
gawin has joined #dri-devel
Guest10209 has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
camus has quit [Ping timeout: 480 seconds]
minecrell has quit [Quit: :( ]
<pq>
Would anyone happen to have an idea why a benq monitor (144 Hz capable, no VRR) would radically become a lot brighter when I change fixed refresh rate from 60 to 24 Hz?
<emersion>
does it stay brighter?
<pq>
after doing what?
<pq>
changing back to 60 Hz makes it go back to normal brightness
<pq>
OSD brightness and contrast controls show the same value in both modes
<pq>
All rates between 50 - 144 are normal brightness, and the two ~24 Hz modes are overbright. (No modes in between.)
<MrCooper>
some kind of movie mode maybe?
<pq>
that's the best guess so far
<pq>
I just wanted to have a try on gaming with low refresh rate, for curiosity.
<pq>
a cvt 30 Hz mode is overbright, 40 Hz mode screams unsupported :-p
DPA has quit [Ping timeout: 480 seconds]
<pq>
Whelp, so much for that. Good to realize that monitors could do crazy things based on refresh rate.
DPA has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<glennk>
pq, maybe check for a fw update on the monitor?
aravind has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
nchery has joined #dri-devel
jkrzyszt has joined #dri-devel
tzanger has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
thellstrom has joined #dri-devel
tzanger 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
pochu has quit [Quit: leaving]
itoral has quit [Remote host closed the connection]
kts has joined #dri-devel
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
agners has quit [Read error: Connection reset by peer]
agners has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
GyrosGeier has joined #dri-devel
<GyrosGeier>
hi
<GyrosGeier>
I have a segfault in Mesa if $DISPLAY points to a remote display and I try to find out which local Vulkan driver corresponds to it
<GyrosGeier>
(the correct answer should be "none")
<GyrosGeier>
there are a bunch of uninitialized variables in that because I was swapping parts around to avoid a crash on nV
kts has joined #dri-devel
<GyrosGeier>
querying for physical device surface capabilities or surface formats falls over on nV if $DISPLAY points to a remote connection, so I'm trying to test first whether any queue on the current device has present support
<GyrosGeier>
but this falls over in Mesa, even without the proprietary drivers, it seems
<GyrosGeier>
for some reason, xcb returns a NULL pointer here
gawin has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
fahien3 is now known as fahien
fxkamd has joined #dri-devel
kts has joined #dri-devel
<fahien>
Hi, I am looking at VK_EXT_image_drm_format_modifier, and it is not clear to me how the VkFormat-DRMformat translation would work. The thing I do not get is how a DRM format modifier would interpret its components, while Vulkan is quite straightforward with its "identification of formats" (UNORM, SINT, ..).
<fahien>
errata corrige: "how a DRM format would interpret its components"
ella-0_ has joined #dri-devel
bluebugs has quit [Remote host closed the connection]
bluebugs has joined #dri-devel
Major_Biscuit has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<GyrosGeier>
fahien, it's supposed to be somewhat opaque
ella-0 has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<GyrosGeier>
as far as I understand it, this is for negotiating the optimum layout for shared buffers
<fahien>
GyrosGeier do not we have DRM format modifiers for that?
<GyrosGeier>
yes
<GyrosGeier>
the compositor would ask the GPU driver what would be the optimal layout for an applications present buffer
<GyrosGeier>
then tell the application to use this layout if possible
<GyrosGeier>
at least that's how I understand it
nchery has joined #dri-devel
<GyrosGeier>
if the application uses a different graphics API than the compositor, the only common format number space is the one from the local graphics driver
bluebugs has quit [Ping timeout: 480 seconds]
<GyrosGeier>
i.e. a Vulkan based compositor and an OpenGL based application could both use the respective drm_format extension to agree on a buffer layout that is opaque to both of them
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
<fahien>
Cool, it makes sense to me, thanks. The question now is: once I have a shared buffer with a certain DRM format, how do I interpret its components? As floats? As signed integers?
<GyrosGeier>
you don't
<GyrosGeier>
it's meant to be an interchange format
<GyrosGeier>
so the producer renders into a buffer with the negotiated format, and the consumer takes data out of there
<GyrosGeier>
so a compositor would use a copy operation from <opaque interchange format attached to a buffer object> to <screen space format>
<GyrosGeier>
or, if it uses a shader, it would create a texture sampler that refers to the opaque format, and pass that to the shader
<MrCooper>
this can only work if both parties agree how to interpret the channels of the format :) which is what I think fahien is getting at
<GyrosGeier>
ah
<GyrosGeier>
my expectation would be that this also happens magically
<MrCooper>
it seems to be implied by the format name, those with 'F' after the channel sizes are floating point, rest probably unorm?
<GyrosGeier>
I think if you need to know the format, then the DRM format modifiers extension is the wrong extension to ask
<GyrosGeier>
and instead you ask the appropriate API in whatever graphics library you use
zackr has joined #dri-devel
<GyrosGeier>
like "I have a buffer that is laid out like the compositor wants it, what is its OpenGL format number?"
heat has joined #dri-devel
<zamundaaa[m]>
I'm pretty sure that Vulkan can't tell you what format a buffer you import is. The dmabuf doesn't contain any special information AFAIK
nchery has quit [Ping timeout: 480 seconds]
<GyrosGeier>
yes
<GyrosGeier>
but you can create a buffer with a specific DRM type, and then ask what its Vulkan type is
<GyrosGeier>
at least that's my interpretation
<GyrosGeier>
the dmabuf itself doesn't communicate any format info, so this needs to be passed in a side channel
<zamundaaa[m]>
drm formats are just channels + bit counts, they don't contain any format info beyond that. 10 bits could be signed, unsigned integers or floating point. Which is what fahien asked about
<GyrosGeier>
hmmm
<GyrosGeier>
I see
bluebugs has joined #dri-devel
JohnnyonFlame has joined #dri-devel
nchery has joined #dri-devel
<fahien>
I am starting to think that
Haaninjo has joined #dri-devel
<fahien>
it does not really matter, while I can look at the Vulkan "identification" to see how data is interpreted, raw data is still the same under the hood.
<karolherbst>
mhhh.. I broke gitlab for me :(
<karolherbst>
ahh.. seems to work again
* GyrosGeier
has fun with NULL pointers
<GyrosGeier>
apparently, xcb generates a NULL pointer when querying the DRI3 extension's version number through SSH
<GyrosGeier>
all I want is some more or less graceful degradation
<karolherbst>
GyrosGeier: "remove X" -> people stop caring
<karolherbst>
*remote
<karolherbst>
also, it seems like the bug tracker is so broken, the page doesn't even load
Duke`` has joined #dri-devel
mbrost has joined #dri-devel
<zamundaaa[m]>
fahien: it does matter. If you use the wrong Vulkan format, the program reading the data (be that you, or the Wayland compositor) will read garbage
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<zamundaaa[m]>
I checked what Sway does and they're using the matching srgb format with inverted endianess. So that's unsigned integers
<GyrosGeier>
karolherbst, the Xorg.log is a bit large
<GyrosGeier>
and I don't even need it to work over remote X, I just need it to tell me "no" without segfaulting :<
<GyrosGeier>
I should possibly also test what happens if I have two graphics cards and one of them has Vulkan drivers and the other one is running X11
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<MrCooper>
zamundaaa[m]: there are floating point formats, DRM_FORMAT_[AX][BR]G[BR]16161616F
unerlige has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
JohnnyonFlame has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lstrano has joined #dri-devel
gouchi has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
LexSfX has quit []
Major_Biscuit has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
LexSfX has joined #dri-devel
LexSfX has quit []
mlankhorst has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
rasterman has quit [Quit: Gettin' stinky!]
tango_ is now known as Guest10261
tango_ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
jljusten has quit [Ping timeout: 480 seconds]
rakko_ has quit [Remote host closed the connection]
rakko_ has joined #dri-devel
rakko_ has quit [Remote host closed the connection]
Guest10261 has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
ybogdano has joined #dri-devel
jljusten has joined #dri-devel
<jenatali>
Huh, just hit an assert that should be hitting every nir driver that supports tessellation during a piglit shader run. Interesting
<zmike>
🤔
<jenatali>
And there's another one... getting very confused
<pq>
glennk, oh, it didn't even occur to me it might be unintended behavior.
eukara has quit []
eukara has joined #dri-devel
<pq>
fahien, zamundaaa[m], I do not think that DRM format could be "10 bits could be signed, unsigned". The DRM format spec defines it: if it says nothing else, then it is UINT/UNORM (whichever way to prefer to look at it, it's the same). There are also explicit floating-point and shared-exponent formats. I don't recall seeing any signed formats.
<jenatali>
zmike: You did tess support, right?
<jenatali>
Any chance you could check out arb_tessellation_shader/execution/vs-tcs-tes-tessinner-tessouter-inputs-quads? This asserts in nir_lower_system_values because it tries to generate load_tess_level_inner/outer as loading a vec2/vec4, but these vars are float[2]/float[4] and are loaded one at a time for me
<jenatali>
And the row selection just gets dropped during that intrinsic generation
<jenatali>
O.o
mlankhorst has joined #dri-devel
<jenatali>
Oh. I see it. PIPE_CAP_GLSL_TESS_LEVELS_AS_INPUTS. Cool, that should just be required, glsl_to_nir doesn't work without it
<zmike>
jenatali: problem solved?
<jenatali>
Yep
<zmike>
hooray
<jenatali>
Just need to set a cap. The cap is required for NIR drivers that support tess
<zmike>
maybe add an assert to mesa/st?
<jenatali>
Yeah
<zamundaaa[m]>
pq: I expected it to be defined or mentioned somewhere, just didn't find it
mbrost has quit [Ping timeout: 480 seconds]
<jenatali>
Wee another enum-in-packed-bitfield difference where MSVC treats them as signed and sign-extends
mbrost has joined #dri-devel
<jekstrand>
*sigh*
<jekstrand>
jenatali: where?
<jenatali>
shader_info::tess::spacing
<jekstrand>
:-/
<jenatali>
Yep. Patch incoming :)
<jekstrand>
jenatali: How many vertices are in that patch? :-P
<jenatali>
I think I've got all the ARB_tessellation_shader tests passing, so posting my driver/compiler patches, and then I'll send separate MRs for the 3 common patches
<jenatali>
Hah!
<jenatali>
I prefer control points to vertices :P
tobiasjakobi has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<jenatali>
Only 36 commits \o/
alyssa has joined #dri-devel
<alyssa>
anholt: I see a "pipe_box in pixels to pipe_box in blocks" helper open-coded in v3d_resource.c, would I have your ack to extract that out as an actual gallium util
<jekstrand>
jenatali: I suppose that means you want me to review it. :-P
* jekstrand
should be on vacation, not IRC
<jenatali>
Yep :)
<alyssa>
jenatali: tessellation on d3d12, the mad man :o
<jekstrand>
Yet here I am...
<jenatali>
Whenever you get a chance
<alyssa>
jekstrand: Go to vacation! :p
camus has quit [Remote host closed the connection]
<jekstrand>
tehe
<alyssa>
Make that chance your future employer problem's, not your vacation's! :p
<jenatali>
alyssa: Don't read the nir passes, it's crazy
<alyssa>
(Hm.. did anyone guess Qualcomm yet?)
* jekstrand
is also, aparently, is playing Android maintainer today...
<jekstrand>
alyssa: I don't think anyone's been crazy enough to guess qcom yet.
<Sachiel>
it's Nintendo. Making Vulkan not suck on the Switch
<alyssa>
jenatali: I guess I can make !14400 my employer's problem instead of jekstrand's vacation's problems...
bgs has joined #dri-devel
<alyssa>
jenatali: changes to dead_cf_block look fine
<alyssa>
I'm a little surprised that node_is_dead doesn't need more changes, though, it seems to assume loopness pretty hard
<jenatali>
alyssa: My read on it is that it's making sure that *nested* loops (loops within the potentially-dead node) don't have side effects
<jenatali>
It does look like it handles ifs just fine basically as-is, and it nicely fixes the dead cf I was seeing left around after running the pass
<alyssa>
Yeah, I think you're right
<jekstrand>
jenatali: RB
* jekstrand
is bad at vacationing
<jenatali>
Thanks :)
<alyssa>
jekstrand: here want to write an m1 vulkan driver
<alyssa>
that should distract you from your vacation :-p
<jekstrand>
alyssa: You gonna send me an M1?
<jenatali>
jekstrand: Yeah I spent most of my weekend writing tess patches for whatever reason
<jekstrand>
:P
<alyssa>
* M1 not incldued
<jekstrand>
jenatali: It happens to the best of us, I suppose.
<jekstrand>
alyssa: I am tempted to do M1 Vulkan
<alyssa>
it's wooorking
<jekstrand>
alyssa: It'd give me a good excusde to write a brand new Vulkan driver from scratch and find all the places where we need to beef up common code.
<alyssa>
jekstrand: here want to fix !14217? :-p
<jekstrand>
It'd also give me the chance to play with some ideas I've had kicking around for a while.
<alyssa>
("I was promised Vulkan......")
<jekstrand>
Like implementing Vulkan in Rust.
<alyssa>
grin
<anholt>
yay, the new ntt ra solution seems to be passing tests.
<anholt>
should have done this from the start.
<alyssa>
Woot
<jekstrand>
alyssa: Uh... What was that about me being on vacation?....
<alyssa>
jekstrand: It's for M1! :-p
<jekstrand>
Looks like the cheapest Mac Mini is $700. That's not horrible...
<jekstrand>
Way less horrible than the laptops
<FLHerne>
jekstrand: Samsung
<FLHerne>
they have these new AMD-based GPUs
<jekstrand>
alyssa: How's that kernel driver coming? :-P
<alyssa>
marcan: How's that kernel r/e going? O:)
<alyssa>
FLHerne: Another excellent nerdsnipe
<jekstrand>
FLHerne: Did you hear? Someone on the phoronix forums said that Intel's new GPUs are AMD-based too!
<jekstrand>
We should all go work on RADV, I guess.
mbrost has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<HdkR>
jekstrand: Surely it's not only the lack of M1 making you not work on Asahi mesa? :P
<bl4ckb0ne>
are you saying that because you work for amd now? :D
<ccr>
:D
<ccr>
it's a conspiracy! * plays X-Files theme *
* bl4ckb0ne
goes tell phoronix
<bl4ckb0ne>
or maybe it's android or apple!
<alyssa>
* HdkR visits https://apple.com/ and asks jekstrand for shipping info
unerlige has joined #dri-devel
<HdkR>
If there's one thing I like doing, is improving the ARM ecosystem by slapping people with hardware.
<HdkR>
Hardware should never be something that gates talented and hardworking people from doing work
<daniels>
afaik it’s working for Microsoft, where he’ll be joining jenatali working on the next-gen M6-based Xbox running Proton in Wayland
<alyssa>
can confirm, have way too many HdkR boards
unerlige has left #dri-devel [#dri-devel]
<alyssa>
daniels: M6? like the apple chip from 2027?
<jenatali>
Yep, obviously
<daniels>
but not sure if I should be saying that in public or not
<daniels>
alyssa: y
<alyssa>
I knew Microsoft was up to something when they started with Apple on a Mesa driver
<HdkR>
alyssa: Too many or just the right amount? :thonk:
<gawin>
1: MUL temp[4].xyz, temp[3].xyz_, const[1].xyz_;
<gawin>
(the bug: y and z aren't set to value of x)
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<gawin>
I'm not fully sure if it's possible to easily calculate writemask, like for example by taking swizzle of source from mul operation.
alanc has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<jekstrand>
daniels: If I really were going to be working on the new Wayland+Proton M6-based XBox (which is totally be a thing!), don't you think I'd be working on M1 already?
<jekstrand>
Or maybe I am....
ybogdano has joined #dri-devel
<ccr>
!
<jekstrand>
Or maybe I've finished the M1 driver and I'm already on M4.
<kisak>
there's got to be a British transit joke in there somewhere about things moving slowly
<airlied>
m20 loops forever
<airlied>
or is that.the a20
mdnavare has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<kisak>
M25?
rasterman has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
<jekstrand>
alyssa, HdkR: It's not really a lack of HW that's the problem. I could buy one if I wanted. I'm trying not to start a major side-project right now, headed into a new gig and all.
<alyssa>
Boooooo :-p
<alyssa>
New gig shmew gig
<HdkR>
Everyone needs a hobby right? ;)
<jekstrand>
Yeah....
<airlied>
and the first months of a new gig are just reading powerpoints and trying to work out how to search the intranet and failing
<HdkR>
Or searching the intranet and finding out things that are not meant to be available to new employees. Secrets~
<jekstrand>
Gotta spend a few weeks reading PPTs if you going to know how to make them.
<airlied>
at least a week to find the official ppt template :-P
<jekstrand>
Yeah
<alyssa>
HdkR: My first week at Collabora I think I searched the intranet for myself or Panfrost or something
* bnieuwenhuizen
still doesn't know our template
<HdkR>
alyssa: Oh yea, same for my projects. Always fun
<jekstrand>
The problem at Intel was always trying to figure out which template you were supposed to use. THey were all clearly the wrong one. (-:
<Lynne>
is there any way to debug radv device lost errors, considering that the validation layer reports nothing wrong?
<Lynne>
I don't think it's a driver bug, because libplacebo/mpv already use the functionality
<bnieuwenhuizen>
Lynne: lots of effort and RADV_DEBUG=hang
<Lynne>
oof
<alyssa>
jekstrand: I think I have beamer on my work machine..
<airlied>
my first 3 weeks at rh were arguing with IT about getting my email address correct
<airlied>
it was quite productive since I couldn't do any work without it, but had lots of upstream stuff to do :-P
<bnieuwenhuizen>
and you can dump commandbuffers with umr -o bits --ring gfx_0.0 --waves or something like that
jewins has quit [Ping timeout: 480 seconds]
<Lynne>
yeah, the issue is nothing is really submitted apart from upload/downloads/layout changes
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
alyssa: I can't use Beamer if I'm going to be at Microsoft working on the M6 XBox. It's going to be all PPT.
<alyssa>
jekstrand: Nah, Microsfot ❤️ Open source
<alyssa>
jenatali: right?
<jenatali>
Yep
ybogdano has joined #dri-devel
<jekstrand>
I was terribly ammused the other day when I needed to do some image editing and all I had was a win11 machine and I could just "dnf install gimp"
<jenatali>
jekstrand: winget install gimp
<daniels>
jenatali: but then you don't get everyone's favourite window decorations
<jenatali>
Hm? The X decorations you mean?
<daniels>
Weston's Xwayland decs, yeah
<jenatali>
You could just wsl --install, wsl, apt install gimp :P
<jekstrand>
daniels: They're some great decorations except they don't work properly in jenatali's hacked up weston. :-P
<jekstrand>
Which I'm sure they'll get around to fixing.
<jekstrand>
But I was amused :)
<jenatali>
Yep, probably
<jekstrand>
Could be a Weston bug, though.
<jenatali>
jekstrand: looks like it'd have to be 'winget install gimp.gimp' since there's multiple apps that have 'gimp' in the name, too bad
<jekstrand>
It looks like there's a race with resize.
<jekstrand>
(my decoration bug, that is)
<jenatali>
But it does work pretty seamlessly, I've never used winget before
<jekstrand>
What does it do? Tie into the store?
<daniels>
jekstrand: if you’re maximising, it’s almost certainly a Weston issue which should be fixed when it gets rebased