graphitemaster has quit [Server closed connection]
graphitemaster has joined #dri-devel
camus has joined #dri-devel
deathmist has quit [Remote host closed the connection]
deathmist has joined #dri-devel
Venemo has quit [Server closed connection]
Venemo has joined #dri-devel
khfeng has joined #dri-devel
lygstate has quit [Remote host closed the connection]
jannau has quit [Server closed connection]
jannau has joined #dri-devel
ahajda has joined #dri-devel
bbrezill1 has quit []
milek7 has quit [Server closed connection]
milek7 has joined #dri-devel
bbrezillon has joined #dri-devel
elongbug has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
tursulin has joined #dri-devel
mvlad has joined #dri-devel
mwalle has joined #dri-devel
rbrune has joined #dri-devel
tzimmermann has joined #dri-devel
lynxeye has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
aknautiy has joined #dri-devel
HdkR has quit [Server closed connection]
HdkR has joined #dri-devel
pcercuei has joined #dri-devel
Plagman has quit [Server closed connection]
Plagman has joined #dri-devel
MajorBiscuit has joined #dri-devel
dj-death has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
rkanwal has joined #dri-devel
nchery has quit [Remote host closed the connection]
tanty has quit []
tanty has joined #dri-devel
dj-death has joined #dri-devel
mszyprow has joined #dri-devel
nchery has joined #dri-devel
frankbinns has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
LexSfX has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
lemonzest has joined #dri-devel
rasterman has joined #dri-devel
Company has joined #dri-devel
khfeng has quit [Remote host closed the connection]
khfeng has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
itoral has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
elongbug_ has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
kts has quit [Quit: Konversation terminated!]
Daanct12 has quit [Remote host closed the connection]
adjtm has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
lplc has quit [Ping timeout: 480 seconds]
elongbug__ has joined #dri-devel
<Company>
random question: GTK has support for GL and GLES, but how would it determine which one to use? Asking becuase currently we prefer GL but some platforms (read: embedded or Windows) have crappy GL and decent GLES support, and GTK would want to pick the GLES there
<Company>
is there some generic way to figure that out or does one have to manually maintain a blacklist?
lygstate has joined #dri-devel
elongbug_ has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
nchery has joined #dri-devel
vsyrjala has quit [Remote host closed the connection]
vsyrjala has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
nchery has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
<linkmauve>
Company, you might want to check the version exposed maybe? Like, if there is both GL 2.1 and GLES 3.2 exposed, prefer the latter.
<linkmauve>
In the case of Lima though, which supports GLES 2.0 and a crippled version of GL 2.1, you probably want the former though, but on other drivers (i915 perhaps?) the latter.
nchery has joined #dri-devel
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #dri-devel
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
shankaru has quit [Quit: Leaving.]
nchery has quit [Ping timeout: 480 seconds]
<Company>
linkmauve: that sounds a lot like white/blacklisting is the best option :/
<linkmauve>
Probably. :/
<linkmauve>
Better wait for other opinions though.
Daanct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
jewins has joined #dri-devel
shashank_sharma has joined #dri-devel
shashank_s has quit [Ping timeout: 480 seconds]
vsyrjala has quit [Ping timeout: 480 seconds]
vsyrjala has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
vsyrjala has quit [Remote host closed the connection]
vsyrjala has joined #dri-devel
nchery has joined #dri-devel
mbrost has joined #dri-devel
camus1 has quit []
lygstate_ has joined #dri-devel
camus has joined #dri-devel
adjtm has quit [Ping timeout: 480 seconds]
lygstate has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
<ajax>
Company: there
<ajax>
's a mesa extension that gives you preferred API verion IIRC
<ajax>
Extended renderer info (GLX_MESA_query_renderer):
<ajax>
...
<ajax>
Preferred profile: core (0x1)
<ajax>
Max core profile version: 4.6
<ajax>
which we seem not to have added to EGL yet, sigh
<Company>
I was about to ask
<ajax>
guess i should wire that up
<Company>
the bug in GTK is EGL (read: ANGLE) on Windows
<Company>
so I guess the code will have to live in the GL backend code (GLX, EGL, WGL, AppleGL)
shankaru has joined #dri-devel
iive has joined #dri-devel
<ajax>
Company: in practice we only really lie about things like gl 2.1 for features that don't really get used. i don't expect gtk to really care too much about like ARB_occlusion_query
<imirkin>
it's not a lie... we support occlusion query. to 0 bits of precision ;)
<Company>
myworry isn't Mesa - I can complain here and get a good solution
<Company>
my worry is everything else - like somebody deciding to only have DirectX drivers and using ANGLE to talk to it
<imirkin>
why not just create both contexts and see which one you like?
<Company>
my worry is that I don't know which one I like unless I run somewhat extensive performance testing
<imirkin>
just look at the version? or that's not good enough?
<Company>
because people are smart enough to just redirect to a software renderer
<imirkin>
ah yes. smart.
<imirkin>
sorry, i got nothin' for you...
<imirkin>
there are some EGL exts to tell whether you're on a pure software impl i think?
<imirkin>
it's used to make things not try to run on llvmpipe
<imirkin>
but if it's a mix, you're sunk. also probably a mesa-only ext.
<ajax>
i do encourage everyone to stop caring about drivers that aren't mesa, but i suppose that's not realistic for another year or so yet
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
fxkamd has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<Newbyte>
only another year? do you know something we don't?
x512[m] has quit [Server closed connection]
x512[m] has joined #dri-devel
naveenk2 has quit [Read error: Connection reset by peer]
naveenk2 has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<ajax>
jekstrand: re !15580, your grep of what exactly
<ajax>
((constructor)) is how c++ constructors for globals works, it's a weird thing to object to
<ajax>
as a result of which, i'm reasonably sure?, that it works on not just linux
kisak has quit [Remote host closed the connection]
kisak has joined #dri-devel
<jekstrand>
ajax: As long as we can guarantee there's no dependency between any of them, I think they work mostly ok.
<jekstrand>
If there are any dependencies, even by accident, you're kind-of screwed.
<jekstrand>
Because nothing in any of the specs sorts out the dependencies and ensures they run in the right order.
<jekstrand>
So if the xlib initialization needs CPU detect, we're toast
<ajax>
yeah, i dug into this a bit a while ago. i think we're safe here, ctors run after all your object's deps are loaded and we're only calling things from effectively libc
<ajax>
but they run before dlopen returns, so you're guaranteed the rest of your library happens-after
<jekstrand>
IIRC, global POD object init happen first, then ctors, so if you construct on-demand based on your thing being zero, you're safe always, regardless of order.
<jekstrand>
But if you trust in ctors you need to be 10000% sure that none of them use anything which depends on any others.
ella-0 has joined #dri-devel
<jekstrand>
Which should be true of CPU detect today given that we require it to be explicitly called today
<jekstrand>
I just get scared every time I think about global constructors. I may have a bit of PTSD about them. :)
<ajax>
we could enforce that at ninja build time if you wanted. emit just the probe code as its own trivial executable, link it against libc only, if it ever fails to link you know you added too much
<ajax>
the only other caveat i can see about gcc ctors is the darwin linker doesn't support priorities
<ajax>
also
<ajax>
our only code that truly needs this is in the drivers. the loaders aren't performance paths really
<ajax>
do it there instead
<jekstrand>
Yeah, loaders shouldn't be using ASM
<jekstrand>
I also think doing what I did but with kernel-style READ/WRITE_ONCE() instead of atomics should be safe.
<jekstrand>
And fast
<ajax>
right on, just throwing ideas out that didn't seem baked enough to have a whole thread about in the ticket
oneforall2 has quit [Remote host closed the connection]
mbrost has joined #dri-devel
oneforall2 has joined #dri-devel
heat has joined #dri-devel
shankaru has quit [Quit: Leaving.]
MajorBiscuit has quit [Ping timeout: 480 seconds]
Mis012[m] has quit [Server closed connection]
Mis012[m] has joined #dri-devel
<tjaalton>
'gnome-extensions-app' is crashing here on xorg with crocus but not with i965, works fine on wayland. mesa 22.0.0 or current staging both affected
<ajax>
okay but that code is nowhere near anything wayland-sensitive
<ajax>
y'all building with LTO or something?
<tjaalton>
probably
Duke`` has joined #dri-devel
<ajax>
iirc that's still inadvisable for mesa
<tjaalton>
okay, good to know :P
<ajax>
fedora's turning it off, anyway. if that turns out to be the culprit we should maybe enforce that at configure time
<marex>
mripard_: should I apply the icn6211 to drm-misc-next or should I still wait ?
<tjaalton>
I'll try
<anholt>
ajax: we should probably look at the perf implications, but I think Mesa would be much safer with lto allowed but no strict aliasing (because we don't actually follow those rules)
<anholt>
(my assumption is that most lto-exposed fail is strict aliasing)
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #dri-devel
shankaru has joined #dri-devel
stuartsummers has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
naveenk21 has joined #dri-devel
naveenk2 has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
idr has quit [Quit: Leaving]
idr has joined #dri-devel
<jadahl>
(i915) is it expected that connectors connected via thunderbolt doesn't have HDR_OUTPUT_METADATA properties exposed?
naveenk21 has quit []
mbrost has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
<vsyrjala>
mst?
vsyrjala has quit [Quit: leaving]
vsyrjala has joined #dri-devel
ybogdano has joined #dri-devel
nchery has joined #dri-devel
Guest2835 is now known as chadv
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
lynxeye has quit []
pochu has quit [Quit: leaving]
adjtm has joined #dri-devel
<tjaalton>
ajax: -fno-lto didn
<tjaalton>
't help
<jadahl>
vsyrjala: i believe so. the listed encoders have the type DP MST
<jadahl>
the hdmi port on the laptop itself has an TMDS encoder which has that property
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
jkrzyszt_ has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
lanodan has quit [Quit: WeeChat 3.3]
<vsyrjala>
yeah, we don't have the hdr metadata hooked up to mst for some reason