<xyene>
hi, I was looking at implementing `EGL_KHR_swap_buffers_with_damage` and `EGL_EXT_buffer_age` for llvmpipe, and have something "working" locally that's too hacky to upstream
<xyene>
`drisw_put_image` -> `put_image` -> `dri2_wl_swrast_commit_backbuffer` (or the X11 version)
libv has joined #dri-devel
<xyene>
is the right play here to actually plumb damage rects through all that, or would it be acceptable to stash them in the `struct dri2_egl_surface *`, or something else?
lplc has joined #dri-devel
<jekstrand>
There shouldn't be anything LLVMpipe-specific about the extension.
OftenTimeConsuming has joined #dri-devel
<xyene>
jekstrand: agreed, though we only have the damage rects at the time `dri2_wl_swrast_swap_buffers` is invoked from `eglSwapBuffersWithDamage`, which as (far as I can trace) delegates everything to llvmpipe (not sure if I'm using the right name here? this is all under `gallium/frontends/dri/`), which *eventually* calls back into our
<xyene>
`dri2_wl_swrast_commit_backbuffer`, which is the place we have to communicate the damage to the compositor... so somehow the information somehow needs to make it through all the indirections
<xyene>
in my hacked-up implementation I just stash the rects in global state in egl_dri2.c, but I'm sure this won't fly :)
<jekstrand>
That's possible. LLVMpipe does have some of its own WSI magic.
<jekstrand>
What platform are you on?
<jekstrand>
x11? Wayland?
<xyene>
jekstrand: Wayland at home, X11 at work, so ideally I'd get it working for both eventually
<xyene>
would be starting with Wayland, though
<jenatali>
Ugh... fix a bug, hang CI pipelines, that's fun...
camus has joined #dri-devel
boistordu_ex has joined #dri-devel
<jekstrand>
xyene: Ok, so nothing strange like Windows.
camus1 has quit [Ping timeout: 480 seconds]
<jekstrand>
xyene: It should eventually call dri2_wl_swap_buffers_with_damage somehow.
<jekstrand>
Or dri2_wl_swap_buffers. The question is how to get it to call the later
boistordu has quit [Remote host closed the connection]
<jekstrand>
*former
Company has quit [Quit: Leaving]
aravind has joined #dri-devel
<jekstrand>
The only wl_surface_commit() I see in the code-base is in src/egl/drivers/dri2/platform_wayland.c and the Vulkan WSI code.
Peroverik has joined #dri-devel
<jekstrand>
So it must end up in one of those two even for LLVMpipe
Peroverik has quit []
CounterPillow_ is now known as CounterPillow
Peroverik has joined #dri-devel
Peroverik has quit []
Peroverik has joined #dri-devel
Peroverik has quit []
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
Peroverik has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
Peroverik has quit []
ppascher has joined #dri-devel
<jekstrand>
The phoronix forums are surprisingly on-point... I'm not sure if I'm happy about that or dissapointed.
Peroverik has joined #dri-devel
mclasen has joined #dri-devel
camus has quit [Remote host closed the connection]
camus1 has joined #dri-devel
Peroverik has quit []
Peroverik has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
Peroverik has quit []
Duke`` has joined #dri-devel
Hi-Angel has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
mriesch_ has quit []
mriesch has joined #dri-devel
agx has quit [Remote host closed the connection]
agx has joined #dri-devel
cworth has joined #dri-devel
mupuf_ has quit []
mupuf has joined #dri-devel
itoral has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
JohnnyonFlame has joined #dri-devel
ahajda has joined #dri-devel
Peroverik has joined #dri-devel
Peroverik has quit []
mvlad has joined #dri-devel
fxkamd has quit []
danvet has joined #dri-devel
MajorBiscuit has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mszyprow has joined #dri-devel
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
lemonzest has joined #dri-devel
rando25892 has joined #dri-devel
GyrosGei1r is now known as GyrosGeier
pnowack has joined #dri-devel
tursulin has joined #dri-devel
thellstrom has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
pcercuei has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
shankaru has quit [Remote host closed the connection]
<jani>
anyone here that knows their way around drm writeback connectors? struct drm_writeback_connector embeds both 'struct drm_connector base' and 'struct drm_encoder encoder' and that kind of conflicts with the i915 model of extending drm_connector and drm_encoder by embedding them in intel_connector and intel_encoder, respectively
<jani>
or is the drm_writeback_connector supposed to be an outlier anyway, and not part of the driver's usual handling of connectors and encoders?
<pinchartl>
jani: I don't know much about i915, but on the writeback connector side, the encoder doesn't really control any hardware, it's a dummy drm_encoder that is only created because the KMS uAPI requires encoders (historical mistake, as far as I understand)
<pinchartl>
on ARM systems we're actually slowly moving away from drm_encoder to drm_bridge. drm_encoder will need to be kept as it's exposed to userspace, but the kernel implementation in some drivers is already an empty shell
<pinchartl>
anyway, back to writeback, I don't see a reason to wrap the connector and encoder in i915-specific structures
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
<jani>
pinchartl: I think the danger is that basically *everywhere* in i915, if you get a struct drm_connector *, you can assume it's embedded in struct intel_connector
<pinchartl>
sounds like something to fix in i195 :-)
<pinchartl>
i915
<jani>
well, kind of drm is built around the idea of being able to extend structures
<jani>
indeed drm_writeback_connector does just that
mlankhorst has joined #dri-devel
<jani>
it's just that now we're talking multiple inheritance :o
<jani>
and given so few examples of drm_writeback_connector usage in kernel, I'm really not sure if it's drm_writeback_connector that's not a great model, or if it's i915 that should adapt to that
mvlad has quit [Remote host closed the connection]
rasterman has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
tursulin has joined #dri-devel
hakzsam_ has quit []
hakzsam has joined #dri-devel
itoral has quit [Remote host closed the connection]
tursulin has quit [Quit: Konversation terminated!]
itoral has joined #dri-devel
mclasen has joined #dri-devel
tursulin has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral 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
itoral has quit [Remote host closed the connection]
<tzimmermann>
jfalempe, well. i think we can merge the patch if it comes with a comment. it fixes a real bug and i don't have a good alternative. i'll add soem text when i merge it
<tzimmermann>
does that work for you?
<jfalempe>
yes, sure ;)
<jfalempe>
if we want to be more prudent, we can do the change only for problematic hardware (G200_se with rev42)
<tzimmermann>
jfalempe, no, i think its ok
<jfalempe>
ok that's fine, thanks a lot.
<tzimmermann>
mgag200 doesn't use the vga range. so it probably has no impact.
<jfalempe>
ok
<tzimmermann>
if i hear about regression, i'll get back to you
<javierm>
because IIUC the problem is only with kdump, since kexec should shutdown cleanly ?
<jfalempe>
I think the mgag200 doesn't change this register when unloaded.
<javierm>
jfalempe: but then probably that something to fix (i.e: add a .shutdown callback that does this)
<javierm>
I also wonder how the boot_params->screen_info is handled between kernels when kexec
<jfalempe>
I think is_kdump_kernel() can be used to avoid writing to the VGA interface in kdump mode.
<javierm>
because I wonder if the access isn't a consequence of screen_info.orig_video_mode == 7 not being true anymore when the second kernel is booted
<jfalempe>
.orig_video_mode == 7 is for monochrome monitor
kts has joined #dri-devel
<tzimmermann>
i'd prefer if linux would detect the vga configuration and not print anything if it's not text mode.
<javierm>
jfalempe: ah, sorry I got it backwards. But my question remains, then adding a check for whatever video mode is text
<tzimmermann>
what i mean is: 0xb8000 indicates text mode, but the rest of the hardware has been configured for graphics mode. that might be a problem
<jfalempe>
is there a reliable way to know if the VGA interface is available ?
JohnnyonFlame has joined #dri-devel
<tzimmermann>
jfalempe, by reading the vga registers
pendingchaos has quit [Read error: No route to host]
<javierm>
tzimmermann: exactly. That's what I meant too, the real bug IMO is the kdump kernel trying to use text mode while in graphics mode
<tzimmermann>
the new kernel would be able to read the last framebuffer setup and use it for output
<javierm>
tzimmermann: yeah, that's why I asked how boot_params->screen_info was passed between kernels. But that's tricky because is a global var with no locking
<javierm>
all the code assumes is read-only AFAIK
<tzimmermann>
javierm, right. it's all read-only. and i don't know enough about kdump, but i know someone who might. i'll ask him
<tzimmermann>
it's probably just another multi-year project ;)
<javierm>
tzimmermann: yeah...
cworth has quit [Ping timeout: 480 seconds]
<jfalempe>
and there is a field "__u8 orig_video_isVGA" which looks a perfect fit for that.
<javierm>
tzimmermann: I also know someone who's familiar with kdump, he mantains it even :)
<javierm>
jfalempe: that field is horribly misleading :(
<tzimmermann>
jfalempe, the screen_info structure store the video setup from the initial boot. it's used for early-boot graphics. after kdump/kexec it's probably outdated
<javierm>
jfalempe, tzimmermann: we should ask dyoung about this probably. I'll Cc him in the thread
<tzimmermann>
thanks
<tzimmermann>
if we don't find a short-term solution, i'd still take the patch for now
nchery has joined #dri-devel
cworth has joined #dri-devel
ddevault has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
ddevault has joined #dri-devel
ifreund has joined #dri-devel
minecrell0 has quit []
minecrell has joined #dri-devel
<javierm>
tzimmermann: agreed. The worry is what side effect this could have since if I understand the patch correctly it changes the default mode set by the driver
<imirkin>
this is the definition of how the platform works
<imirkin>
you're trying to run it on a non-properly-initialized platform
<imirkin>
(platform = IBM PC, i guess, in this case)
Duke`` has joined #dri-devel
<javierm>
imirkin: yeah, you are correct too. Probably for kexec/kdump only makes sense to use something like simple{fb,drm} and not a platform fbdev or drm driver
pcercuei has quit [Quit: brb]
off^ has joined #dri-devel
<imirkin>
there are tons of "bugs" filed with more complex GPUs as well with kdump
<imirkin>
there's just not a ton that can be done without a proper init
<javierm>
does EGA and VBE also use a0000? I guess they do
<imirkin>
VBE - yes. EGA, not 100% sure.
<imirkin>
VGA definitely does
<imirkin>
CGA/EGA is a bit before my time
<javierm>
this seems to be nostalgia week :)
<imirkin>
every week is nostalgia week for me ;)
<imirkin>
i just got a text on my phone that 3G service is going to be discontinued...
pcercuei has joined #dri-devel
heat has joined #dri-devel
eukara has quit [Read error: Connection reset by peer]
aravind has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
<tzimmermann>
javierm, i think vbe is mapped
tzimmermann has quit [Quit: Leaving]
pcercuei has joined #dri-devel
ManMower has joined #dri-devel
eukara has joined #dri-devel
<zackr>
javierm: i just noticed that since your d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") and the subsequent patches that enabled simplefb on arm64 vmwgfx stopped loading because it used to pci_request_region and *remove_conflicting_framebuffers while removing simplefb doesn't free sysfb resources. it seems that in general drm drivers do not call pci_request_region[s] do you happen to know if that's the
<zackr>
wanted/expected behavior?
Peste_Bubonica has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
vals_ has quit []
tango_ has joined #dri-devel
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
frieder has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<javierm>
zackr: hi, sorry I was in a meeting. The resource that are requested but not freed is in drivers/firmware/sysfb*.c or drivers/video/fbdev/simplefb.c ?
ella-0_ has joined #dri-devel
Peste_Bubonica has quit [Ping timeout: 480 seconds]
ella-0 has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<daniels>
anholt: another reason to rationalise pipelines - we had a LAVA blip earlier where every job was failing for a while. looking closer at it, we were sustaining 200Mbit/sec pull for 35min
<jenatali>
daniels: I'm thinking we should split the Windows container job in 2: One that pulls non-test deps (like LLVM, VS, etc) and one that pulls piglit. I want to be able to pick up test fixes without having to wait 2 hours for an LLVM rebuild. Thoughts?
Peste_Bubonica has joined #dri-devel
<jenatali>
Not looking forward to having to sit through that to be able to actually do the split in the first place though..
<daniels>
jenatali: yeah strong agree - including with your follow-up …
ahajda has quit []
<jenatali>
I'm honestly wondering if maybe we should split it even further: 1) VS install, 2) LLVM build/install, 3) everything else except piglit, 4) piglit
<jenatali>
1 and 2 will almost never happen, 3 we can deal with the little bit of extra pain for rebuilding all of these if we need to upgrade one, and piglit can be independent for test fixes
<jenatali>
I dunno the implications of that though. Container storage? Network? Impact on the rest of the CI?
<daniels>
the thing which surprises me the most is the sheer amount of time it takes to just resolve the running container back to an image - I have no idea if adding further layers would make that better or worse since Docker on Windows is somewhat of a mystery to me
<jenatali>
Either way I'd want to wait 'til !14413 lands before even trying to start that kind of refactor
<jenatali>
Yeah, I've seen that too, but only for the "build Mesa" job, it's always super fast for the original container building job and the test jobs
* jenatali
only vaguely understands any of this
<daniels>
yeah, it seems to be only the commit, where ... well I assume it just walks the entire fs and compares the lot?
<daniels>
on Linux overlayfs2 helps you out quite a bit
lstrano has joined #dri-devel
ahajda has joined #dri-devel
ybogdano has joined #dri-devel
heat has quit [Read error: No route to host]
heat_ has joined #dri-devel
mvlad has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
<jenatali>
Ugh I have a change that hangs piglit in CI but it runs to completion locally. I want to use piglit's --timeout feature to see which one it is, but it's broken on Windows (just drops the timed out test from the log). So I want to fix that, but then that requires this whole container song and dance
camus has quit [Ping timeout: 480 seconds]
<imirkin>
jenatali: just make sure you still remember why you were originally doing all this by the time you get it all done...
<jenatali>
Right?
<imirkin>
instead of a stack, i have a circular buffer in my head, so it can drop off :)
flto_ has joined #dri-devel
camus has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
camus1 has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
flto_ has quit []
flto has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
<daniels>
jenatali: hack the container locally, push to your own repo, fire jobs against that?
<jenatali>
That requires learning how to use docker :P
imre_ has quit []
Guest635 has quit []
imre has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
jagan_ has joined #dri-devel
<daniels>
create a personal access token through your GitLab user prefs with read_registry+write_registry; docker pull $foo; docker exec --name haxhaxhax -ti $foo powershell; [do whatever you need to inside the session]; docker commit haxhaxhax registry.freedesktop.org/jenatali/mesa/somecontainername:sometag; docker push registry.freedesktop.org/jenatali/mesa/somecontainername:sometag
<daniels>
(where $foo is the current base container you want to mash)
<jenatali>
Thanks, I might give that a shot
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.3]
OftenTimeConsuming has joined #dri-devel
gouchi has quit [Remote host closed the connection]
* karolherbst_
wished having more time to work on mesa :(
* imirkin
wished having more time
<imirkin>
or maybe everyone can take a 2 month vacation and i can catch up? :)
<karolherbst_>
imirkin: sure 2 months are enough?
<imirkin>
no, but it's a start
karolherbst_ is now known as karolherbst
<imirkin>
i think it'd be unreasonable to ask for more :)
<daniels>
in fairness the entire silicon industry did already take a 2-year holiday
<karolherbst>
daniels: funny
<agd5f>
daniels, more like packed 3 years of projects into 2
<daniels>
agd5f: whatever it was, it let you land modifiers, so I'm not going to complain :)
<karolherbst>
although I think I was successful in piling up random stuff on my todo list...
sadlerap3 has quit []
sadlerap has joined #dri-devel
<jenatali>
Ugh wtf, why are these tests hanging and why can't I reproduce it...
Haaninjo has joined #dri-devel
<imirkin>
if $user != jenatali: crash
jekstrand has quit [Quit: Re-arranging my desks]
<zf>
is it documented anywhere how to use softpipe or llvmpipe as a driver for clover?
kts has quit [Quit: Konversation terminated!]
<zmike>
GALLIUM_DRIVER=softpipe
<zmike>
though probably only llvmpipe works
<zf>
that alone doesn't seem to be enough, clinfo is only listing the hardware device
<FLHerne>
Old phoronix article says it needs LP_DEBUG=cl
<FLHerne>
but that might no longer be true
<FLHerne>
...or, indeed, have been completely wrong in the first place?
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
<zf>
I saw that too, but it doesn't make a difference
mbrost has joined #dri-devel
ahajda has quit []
ybogdano has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
jekstrand has joined #dri-devel
ngcortes has joined #dri-devel
gouchi has joined #dri-devel
curro has joined #dri-devel
<jenatali>
Huh, it's out-of-memory...
mi6x3m has joined #dri-devel
mi6x3m has left #dri-devel [#dri-devel]
mi6x3m has joined #dri-devel
<mi6x3m>
hey, need some help understand some basic stuff about mesa
<mi6x3m>
I'm trying to compile a standalone GL.a containing GL, GLX and the respective driver I need (i915)
<imirkin>
that's ... ambitious
<mi6x3m>
am I correct that GLX usually loads the respective driver by driOpenDriver and then dlsym's a "driver_descriptor"
<anholt>
tomeu82: heads up, iris-rebalancing looks like it may be triggering some max-varyings flakes.
<karolherbst>
mi6x3m: not to question your goal here, but I think using vulkan probably achieves the same thing, just better
<anholt>
or maybe you're just running new piglit jobs. regardless, seeing some new flakes there
<mi6x3m>
karolherbst, not my choice here, it is to be used with wine =)
<karolherbst>
(in case reducing CPU overhead ist your goal)
<karolherbst>
mi6x3m: but... that aside, bundling a GL driver is probably not a good idea
<karolherbst>
I am sure many users will hate you for doing it (and us as well, once we have users hitting bugs from inside bundled OpenGL implementations)
<karolherbst>
so I think the bigger question here is: what's the end goal here
<karolherbst>
and why would you even want to have a GL.a
<karolherbst>
because it doesn't make a lot of sense
<ajax>
mi6x3m: that's about right, yeah
<mi6x3m>
well, you see, I have this crazy side project of compiling a self-contained 32 bit wine
<mi6x3m>
which depends on nothing else but the .DLLs
<ajax>
you'll definitely be patching mesa to do it, we very much assume we're dynamically linked
<anholt>
that sounds like the kind of "causing myself problems on purpose" that we shouldn't really be debugging in this channel.
<mi6x3m>
ajax, yeah, that's clear, so i'm probing to understand what will be involved
<karolherbst>
anholt: yeah.. my thought exactly
<karolherbst>
mi6x3m: we tell you to not do it :)
xlei has quit [Quit: ZNC 1.9.x-git-167-81df4dec - https://znc.in]
<karolherbst>
I don't really see 32 bit going away soon anyway, given all the 32 bit games we have
<mi6x3m>
i am not questioning MESA's architecture at all :) fan of the project for many years =) just probing around
<ajax>
or, we'll tell you (i'll tell you) that it's pretty much just gluing iris_dri.so and libGL.so together at link time and undoing anything involving dlfcn.h
<mi6x3m>
ajax, yeah, thats exactly what i'm after, however i have a hard time navigating how the _dri.so is loaded (yet)
<karolherbst>
mi6x3m: I think my problem with that is mainly, that I don't see what problem it tries to solve. If it's just for the fun of it, then yeah, please go ahead and do it, but it shouldn't reach random users ever :D
mvlad has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<ajax>
mi6x3m: src/glx/dri_common.c iirc
<ajax>
and/or src/loader/ if you're dri3? i think? sort of a mess.
<mi6x3m>
karolherbst, i'd never cause such mental anguish on purpose
MajorBiscuit has joined #dri-devel
<karolherbst>
mi6x3m: yeah.. that's totally fine then. I just always fear that sometimes some people have... weird reasons to do it.. like shipping software this way or something. so I mainly want to be sure that this won't be used for weird stuff
Peste_Bubonica has quit [Remote host closed the connection]
<mi6x3m>
there is no business entity behind me, this is only me and I have to be retarded to ship an abomination to someone :]]
<mi6x3m>
such as a 1GB .so file
<karolherbst>
mi6x3m: I thought we have llvm.so for that :D
<mi6x3m>
yeah, llvm is a huge reason for my goals
<mi6x3m>
it's so sad that gallium 9 requires it
<imirkin>
huh?
<mi6x3m>
(that's what meson told me)
<imirkin>
meson lies
<imirkin>
what?
<imirkin>
oh crap
<mi6x3m>
ehhhh?
<imirkin>
for the software rendering that d3d9 requires
<mi6x3m>
are you kidding me
<imirkin>
very sad
ybogdano has joined #dri-devel
<imirkin>
technically llvmpipe is not needed
<imirkin>
you just need swrast
<imirkin>
(i would assume)
<anholt>
softpipe to the "rescue"
<imirkin>
if with_gallium_st_nine
<imirkin>
if not with_gallium_softpipe
<imirkin>
error('The nine state tracker requires gallium softpipe/llvmpipe.')
<imirkin>
llmvpipe is not needed.
<imirkin>
just need software rast of some sort
<mi6x3m>
mhmm so i've been broadcasting fake news but why does d3d require software rendering_
<imirkin>
that's a somewhat philosophical question
<mi6x3m>
ajax, both DRI and Gallium drivers are loaded through driOpenDriver no?
<imirkin>
mi6x3m: apparently ProcessVertices() needs it
<ajax>
mi6x3m: at this point there's no distinction. "DRI driver" just means the driver interface and "gallium" means the core opengl logic and all remaining DRI drivers are gallium drivers
<imirkin>
whatever thatis
<jenatali>
mi6x3m: Software vertex processing. It requires the ability to run transform and lighting on the CPU
<imirkin>
i guess technically it doesn't _have_ to be on the CPU
<mi6x3m>
is swrast also loaded dynamically?
<zf>
it doesn't really "require" software rendering, but it's documented as using it
<ajax>
swrast is a driver like any other
<imirkin>
but ... there's no real "other way" without a compute shader
<ajax>
so, yes, loaded dynamically
<jenatali>
Heh, I guess you could run the VS and then use stream out?
<imirkin>
maybe nine should do that.
<zf>
you can use transform feedback, yeah
<karolherbst>
imirkin: compute shader would be a fun idea :D
<karolherbst>
jenatali: I am sure there is some fun detail why that isn't possible
<jenatali>
Probably
<jenatali>
Windows D3D9 does it in software
<zf>
we haven't implemented it yet, but as far as I'm aware it's possible
<mi6x3m>
hmm, the docs say nothing about doing it in software
<mi6x3m>
but that's beyond me, i'm just the static linkage guy
<karolherbst>
mi6x3m: the problem was rather, that back at the time, hw probably couldn't
<imirkin>
yeah, xfb is a DX10 feature
<imirkin>
most importantly, XFB won't work
<imirkin>
since XFB is pre-clip
<imirkin>
but this wants clipping
Duke`` has quit [Ping timeout: 480 seconds]
<imirkin>
this is the equivalent the select buffer in GL or something
<mi6x3m>
karolherbst, yeah, sounds like something that wouldn't go very well with fixed/inaccessible pipeline
<imirkin>
(hm, or not quite clipping? but something to do with clipping...)
<mi6x3m>
quite likely 100% software
camus has joined #dri-devel
<mi6x3m>
ajax, so if DRI is just the driver interface and gallium the common denominator, why is there a build time distinction (in meson for instance)
<imirkin>
huh... in practice, it _is_ implemented with xfb
<imirkin>
just with swrast?
camus1 has quit [Ping timeout: 480 seconds]
<imirkin>
i'm sure there's _some_ reason beyond just some GPUs not having xfb
<ajax>
mi6x3m: because we haven't cleaned that up yet, tbh
<ajax>
dropping the non-gallium drivers was relatively recent and we're still working through simplifying the remainder to match
<mi6x3m>
oh, good thing i finally showed up here than :) it was driving me insane
<mi6x3m>
something just wasn't fitting, that clears it
<mi6x3m>
why is glx loading the GL.so if glx IS part of the GL.so?
<karolherbst>
imirkin: probably some gallium thing only swrast implemented or something
<ajax>
uggggh why are you making me remember this
cef is now known as Guest976
<jenatali>
imirkin: Could be so that it uniformly supports drivers that have xfb and ones that don't?
<mi6x3m>
sorry, I spent 2 days trying to piece it together :}}
cef has joined #dri-devel
<imirkin>
jenatali: yeah, could be that it was necessary anyways, and since it has ~0 users, wasn't ever hooked up in hw
<ajax>
mi6x3m: iirc the bug that's fixing is: some apps bind to libGL through a dlopen(RTLD_LOCAL), which is the only thing getting libglapi.so into the link map; and the driver needs libglapi symbols but doesn't itself link to glapi and expects the loader (libGL or libEGL) to provide it
<jenatali>
There's more than 0 users, unfortunately :(
<imirkin>
jenatali: well, more than 0, but less than 1? :)
<jenatali>
I wish
<ajax>
so even though libGL itself dlopens the driver, it can't dlopen it into the same "local" scope as the app loaded libGL into, because libdl isn't really that great
<jenatali>
A few years back we deleted the hand-rolled assembly that was used to implement it and switched it to C code, which made it slower, and we heard about that perf difference. There's enough users of it that it made some noise
<ajax>
hence libGL promotes itself to RTLD_GLOBAL
<imirkin>
jenatali: sadness. i guess you have slightly wider reach than gallium-nine though?
<jenatali>
Slightly :)
<ajax>
mi6x3m: all of which ain't a problem for you! you can just #if 0 that away.
Guest976 has quit [Ping timeout: 480 seconds]
<anholt>
jenatali: did you have hand-rolled 3dnow asm, though?
<imirkin>
only 3dlater asm...
<jenatali>
anholt: No, I think just x86
<mi6x3m>
ajax, oh my goodness, I see the road of development was quite a rough one
<ajax>
(this is all stupid and broken and i'm pretty sure we could fix it better by now)
danvet has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<mi6x3m>
probably but i understand better no, thank you a lot :)
<ajax>
'git blame' on those lines would probably find a commit message with the real details
<mi6x3m>
ah, good idea, I tried going through the commits yesterday to see how the file was put together
<mi6x3m>
but git blame is a faster way
boistordu_ex has quit [Ping timeout: 480 seconds]
<mi6x3m>
thanks everyone for being patient and friendly!
<ajax>
np, good luck with your craziness
Haaninjo has quit [Quit: Ex-Chat]
gawin has joined #dri-devel
Anorelsan has joined #dri-devel
<mi6x3m>
ajax, thanks, do you happen to know what GALLIUM_STATIC_TARGETS is doing?
<ajax>
nope
boistordu has joined #dri-devel
<airlied>
that puts all the gallium drivers into the same library
<airlied>
there is also an option to dynamically load gallium "pipe" drivers, but GL doesn't use it
<airlied>
zf: LP_CL=1
* airlied
realiess I've been unregistered
<airlied>
jenatali: so you going to be moving to fine tuning World of Warcraft now? zmike can probably do better rumours
<zf>
that's still not enough :-/
<airlied>
zf: yeah you need to make sure ti's built with all the right things
<zf>
I'm guessing I need some equivalent of LIBGL_ALWAYS_SOFTWARE=1, but I don't know what that would be
<airlied>
no you don't need that
<jenatali>
airlied: Yep, obviously
<airlied>
it's mostly about making sure spirv-llvm-translator and libclc are built correctly
<mi6x3m>
airlied, in the same _dri library?
<jenatali>
I mean I was the one who helped put it on Win7 in the first place :P
<jenatali>
Er, with D3D12 support
<airlied>
mi6x3m: the driver so contains multiple drivers
<airlied>
so say iris_dri.so
<zf>
airlied, I don't see why spirv would be relevant?
<jenatali>
The CL compiler stack always goes through SPIR-V
<airlied>
zf: just because you don't see it, doesn't change that it is :-)
<zf>
oh, good to know
<airlied>
but yes we always use spir-v internally
pcercuei has quit [Quit: dodo]
<zf>
anyway, it is a distribution package, so maybe it's missing something
<zf>
but pipe_swrast.so exists at least
<airlied>
likely libclc is missing something
<zf>
and the radeonsi opencl driver seems to work fine
<airlied>
probably missing spirv-mesa3d-.spv
jewins has joined #dri-devel
<gawin>
question to people with domain: do you (self) host mail server? creating new username for each web account seems nice, but process looks tiring
mi6x3m has quit [Quit: Leaving]
<jekstrand>
gawin: Google apps for me
<Kayden>
no, I stopped doing that years ago. these days I'm using rackspace's email...fastmail also seems solid. or gmail, obviously.
<jekstrand>
It's $5/month and you get the GMail web UI if that's a thing you like.
<Kayden>
at the time I switched, I was getting a ton of spam, and realized that techniques like spamassassin analyzing the contents of your email weren't being terribly effective these days. the larger providers anti-spam systems were based on simultaneous connections and delivery of similar looking emails to thousands of accounts on their mail server
<Kayden>
and you unfortunately had to be a massive mail host like gmail / fastmail / whatever in order to do that kind of stuff. me with my own mail server wasn't going to be able to.
<emersion>
graylisting helps
<dcbaker>
I use fastmail, it does what I want
ybogdano has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
Hi-Angel has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
Anorelsan has quit [Quit: Leaving]
heat_ has quit [Remote host closed the connection]
sdutt has quit [Read error: Connection reset by peer]
join_subline has quit [Remote host closed the connection]
mbrost has quit [Remote host closed the connection]
<cworth>
gawin: I'm still putting up with the limitations of self-hosting implied above, (but only because I'm not willing to give up the feature of all my data residing inside my home).