<ajax>
kopper branch updated but still some feedback left to go
<zmike>
I'm planning to tackle the zink parts this afternoon
<zmike>
ish
<zmike>
also how did your flush MR explode the import test
<ajax>
no goddamn clue
<ajax>
looking at that next because wtf
<ajax>
it almost makes sense because glXImportContextEXT is the other non-trivial caller of __glXIsDirect because you can only import indirect contexts
<ajax>
i could be convinced we should just let the server generate that error for us, because it will, but that just masks whatever problem i introduced
<zmike>
mind-blowing
<ajax>
so anholt said maybe rename some things to not be "drisw" anymore since we're not really software
<ajax>
it strikes me that the appropriate namespace for Layered instead of SoftWare drivers is dril
<ajax>
oh wait no
<ajax>
glXImportContextEXT is the client API but the wire request is GLXQueryContext. and ImportContext generates no error but returns NULL if called on a direct context, but QueryContext has no idea why it's being called because GLX 1.3 added glXQueryContext
<ajax>
so you really do have to check directness
<zmike>
brain hurty
<ajax>
apologies for using the channel to externalize my debugging monologue, i can stop if it bothers
<zmike>
I appreciate a good rubber ducking
<ajax>
hah
<ajax>
i can't test this easily because the X stack i'm running is new enough to have my patch to disable GLX_EXT_import_context if the server has indirect contexts turned off since they won't work
<ajax>
so i just get a PIGLIT_SKIP because i'm running newer X than CI is
<ajax>
and, if i forcibly enable it in the glx extn string, it gets just a plain fail when the indirect context doesn't init.
<ajax>
which... suggests... that CI has iglx turned on?
<ajax>
anholt: ^ sanity check me? i don't see the word "iglx" in the CI scripts (or anywhere) but maybe debian is weird?
<ajax>
nm, the CI test isn't like segfault crashing, it's just getting an X error in a new place.
<zmike>
sounds like ci should just update
<ajax>
okay triple-checked that i'm testing what i mean to test and i still can't repro
<ajax>
i'm going to go back to figuring out why the XFlush helps at all
<zmike>
madman
cheako has quit [Quit: Connection closed for inactivity]
<ajax>
last good is ecca2564c160d45cc0cf082325df1939538ea5c6 first bad is 9153fb7fbe106d3e14f10b48bfb26d3ff975ee44, the two in between throw an assert in radv:
<zmike>
if you still have it available, any chance you can test nvidia so I can ping and tell them their driver is also broken?
<ajax>
haven't powered that machine up in a minute so i have no idea how out of date it is, but i should revive it anyway
<ajax>
will test but it may take a moment
<zmike>
yea np I prob need to swap to nv mode soon anyway to see how close to conformance I am there
<ajax>
so that xcb error about XInitThreads bugged me
<ajax>
because xlib is the one emitting that error, and xlib knows whether XInitThreads was called or not
<zmike>
🤔
<ajax>
so i wrote the obvious patch to print something different if XInitThreads was called
<ajax>
and it still prints the old message
<zmike>
system xlib vs /usr/local?
<ajax>
nope. by "wrote the obvious patch" i mean "and applied it to a local rpm build, which i then installed"
<zmike>
just checking
* zmike
still does this surprisingly often
<ajax>
yeah, if i find myself too deep in LD_LIBRARY_PATH= it's time to build a package, ime
<zmike>
haha
<zmike>
I just have a script that sets up all my env and sometimes I forget to source it over ssh
<ajax>
so this is a problem because mesa is using xcb precisely because it wants to do things in multiple threads reasonably safely
<ajax>
so i can't require the caller to have set up thread safety for me, that's dumb
<ajax>
though i am not opposed to adding an elf ctor to libGL to call XInitThreads. that'd be an idea.
<zmike>
you really can only think of the most masochistic ideas huh
<ajax>
i'm a fan of the drastically effective, what can i say
<zmike>
relatable
<zmike>
why is xlib always so horrible
<ajax>
engineering tradeoffs from a different era
<zmike>
simpler times
<ajax>
your framebuffer is just some more ram attached to the system bus. you have a 68020, you can retire 4 pixels per cycle at 8bpp full throttle.
<ajax>
nobody cares about threads because just having the one cpu all in a single silicon package is still a pretty nifty innovation
<Sachiel>
all a plot from those wayland people to make X11 look bad and push their agenda instead
<ajax>
actually that's the wrong way around
<ajax>
what i need is to put the magic ctor in libX11
<ajax>
and have it walk the link map looking for libraries like pthread or GL that it knows are likely to mean threading gon' happen
eukara has quit []
eukara has joined #zink
<ajax>
so if you just forcibly call XInitThreads in libX11's elf constructor the total performance impact appears to be that X_NoOperation request throughput is 55% slower
<ajax>
on any operation that performs literally any rendering you cannot measure the impact for single-threaded x11perf tests
<zmike>
hmmm
<ajax>
hilariously if you do any work at all you can retire more primitive operations than if you just no-op
<ajax>
you can draw 180M 1x1 rectangles per second. you can issue 111M or 63M no-ops per second.
<ajax>
the or being whether you forced XInitThreads on or not
<ajax>
so it is literally not worth it to preserve the thread-unsafe path through xlib
<ajax>
and this with me just slamming thread safety on, if you bothered to optimize things by like eliminating the function pointer indirections you could probably end up faster than we already are
<zmike>
so what you're saying is you've found a speed loop
<ajax>
"55% as fast", to be precise. dang it.
<ajax>
computers are wild, man
<zmike>
we should just let them roam free
<ajax>
absence of evidence is not blah blah blah but if i forcibly XInitThreads in xlib that xcb crash goes away
<ajax>
or is really hard to repro anymore
<ajax>
so that's fine. actually really nice to know.
<ajax>
because now i can fix xlib and stop caring about a whole class of problems
<ajax>
which is what i call "didn't even have to use my ak" kinda good day