ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
fxkamd has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
airlied has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
<Frogging101> Should I replicate what it does in radv code, or should I build addrlib structs and call into addrlib?
<Frogging101> I'm leaning towards the former being more acceptable, but I'm not sure
<graphitemaster> Update on my strange bug. If I remove `restrict` from the cubemap image I'm writing to in the shader it works fine on Intel mesa, no garbage data now.
<Frogging101> (re my above question) cc airlied
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
cef has quit [Quit: Zoom!]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
cef has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
<airlied> Frogging101: I'd just call into addrlib
<airlied> we call into it in a fair few places
<Frogging101> Okay
sdutt has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
<graphitemaster> Trying to form a hypothesis as to why restrict would behave differently here
<graphitemaster> Is it possible for the shader compiler to synthesize some form of alias for an image variable and use it?
<graphitemaster> If so that would be a shader compiler bug right if it's doing that on an image variable marked restrict
<graphitemaster> Only hypothesis I have
Company has quit [Quit: Leaving]
pixelcluster has quit [Ping timeout: 480 seconds]
pixelcluster has joined #dri-devel
bbrezill1 has quit []
bbrezillon has joined #dri-devel
JohnnyonFlame has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
camus has quit []
sdutt has joined #dri-devel
sul has joined #dri-devel
camus has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
nchery has joined #dri-devel
Duke`` has joined #dri-devel
pendingchaos has quit [Read error: Connection reset by peer]
pendingchaos has joined #dri-devel
fxkamd has quit []
danvet has joined #dri-devel
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
QwertyChouskie has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
rasterman has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
mehdi has joined #dri-devel
mehdi is now known as Guest7298
kts has joined #dri-devel
Guest7298 has left #dri-devel [#dri-devel]
pendingchaos has quit [Quit: No Ping reply in 180 seconds.]
pendingchaos has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
probablymoony has joined #dri-devel
moony has quit [Ping timeout: 480 seconds]
lygstate has joined #dri-devel
<lygstate> After https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16863, more and more tests are failing
<MrCooper> doras: given that a 3D_FULL_SCREEN profile exists, that probably should be used for 3D full screen apps :)
pcercuei has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Major_Biscuit has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
kts has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
fab has joined #dri-devel
enunes has joined #dri-devel
heat has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
nchery is now known as Guest7306
nchery has joined #dri-devel
Guest7306 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
rsalvaterra_ has quit []
<doras> MrCooper: since it's an AMD-specific configuration that requires root to set (and therefore mostly useless for the average user), I was leaning more towards figuring out whether there's a need for a standard uAPI here, or if it's just AMD's bad defaults/bad heuristics and no other vendor actually needs it.
rsalvaterra has joined #dri-devel
<doras> clever: which distro and kernel do you use? As far as I could tell from the kernel code, the sysfs API is the only way to set it to anything else than the "BOOTUP_DEFAULT" setting.
<doras> So if it's set to "3D_FULL_SCREEN" by default in your case, it likely means whoever provides your kernel had patched it in.
Duke`` has quit [Ping timeout: 480 seconds]
<tleydxdy> doras: on arch kernel and with my card 3d full screen is the default
<doras> tleydxdy: which GPU do you have?
<tleydxdy> rx580
zehortigoza has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
<doras> tleydxdy: do you have any startup script or any performance-tuning daemon/application that could directly or indirectly affect it?
tarceri has quit [Ping timeout: 480 seconds]
<tleydxdy> I saw the default in the code
<pinchartl> is there a way, with a test-only atomic commit, to test plane configuration without having an FB ? I want to check if scaling from/to given sizes is supported, I can create a full commit that would match what I would do at runtime, except that I have no FB available at that point
<tleydxdy> somewhere in smu7*.c?
<tleydxdy> I don't remember
Duke`` has joined #dri-devel
<doras> tleydxdy: ah, then the default likely differs between GPU generations.
<doras> I never had an issue with my RX 580. It all started with the RX 5700 XT that I got last week.
<tleydxdy> well, that sounds like a regression then
<doras> Let me git-blame the line which sets the default for RX 580...
tarceri has joined #dri-devel
<doras> First of all, it seems that only "smu7" defaults to `PP_SMC_POWER_PROFILE_FULLSCREEN3D`:
<doras> And that it was originally added like this, without a real explanation as to why:
<clever> doras: nixos and Linux amd-nixos 5.10.81 #1-NixOS SMP Sun Nov 21 12:46:37 UTC 2021 x86_64 GNU/Linux
* pinchartl wonders if we could create a dummy FB that would always be present and usable only for test-only atomic commits
<pinchartl> it's probably too much of a hack
<pinchartl> or rather allow creating an FB with dummy BOs
CME has joined #dri-devel
CME_ has quit [Ping timeout: 480 seconds]
<emersion> someone mentioned a GETFB call with a zero GEM BO in the past
<emersion> as a potential API extension for test-only commits
<pinchartl> isn't it ADDFB2 that we need ?
<emersion> err, ADDFB
<pinchartl> sounds exactly like what I need
<pinchartl> or maybe a way to create a GEM BO in a standard way (that would work with any device) without allocating backing-store memory
<emersion> maybe it was Sean Paul? it was a long time ago
<pinchartl> essentially a cheap BO for test-only cases
<pinchartl> seanpaul____: ^^
<emersion> a "real" GEM BO which is cheap and can always be scanned out, not sure that'd be possible
<emersion> also, a dummy BO is not enough
<emersion> memory alignment, buffer placement, etc
<emersion> these may make some KMS usage impossible
<pinchartl> it doesn't have to work for real commits
<pinchartl> only test commits
<emersion> I mean, a dumb BO wouldn't describe these things
<emersion> so maybe a test-commit works with a dummy BO, but not with the real BO
<pinchartl> do you mean that things like SRC_[XYWH] values could be accepted with a dummy BO but not work with a real BO ?
<pinchartl> I'd like to be able to test plane placement and scaling
<pinchartl> basically, everything but the BOs
<emersion> yes, that's what I mean
<emersion> driver constraints are complicated
<pinchartl> I can imagine that being the case in theory. in practice... SRC_* validation can certainly depend on the FB (pixel format, pitches, ...), but on the BOs themselves ?
<emersion> if a test works with a dummy BO, drivers can't always guarantee it'll work for any real BO, even if allocated with the scanout flag etc
<emersion> well, for one thing, if you have two GPUs and allocate a BO on the other one... it cannot be scanned out on the first
<pinchartl> right now we have no way to test a plane composition layout before we get an FB for each plane, which is really painful
<emersion> it is
<pinchartl> yes, but that's a problem of whether a BO is acceptable or not for a device
<emersion> with James Jones we had a proposal to properly address this
<pinchartl> I don't see how it would influence SRC_[XYWH] validation
<emersion> but its work
<pinchartl> James' work on the universal device memory allocator (is that how it was called ?) is also something I need, but it's orthogonal to the issue of testing composition layouts without BOs
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<emersion> i'm referring to a XDC presentation
sravn has quit [Quit: WeeChat 3.5]
<emersion> there's a part about KMS, where you'd submit a KMS test commit with a "dummy" BO, and get back "constraints", which you can feed into the allocator (GBM)
<emersion> and get a buffer guaranteed to work for that usage
<pinchartl> yes I've seen that one
<pinchartl> I still think it's a separate issue from composition testing
<emersion> this would fix the issue of getting a buffer not suitable for the usage
<emersion> i don't think so…
<pinchartl> right now I want to test if a plane can scale from a given resolution to full screen in a given mode
<pinchartl> and at the point where I want to test that, I have no FB
<pinchartl> James' work won't help with that use case
<emersion> it can, see above
<emersion> > you'd submit a KMS test commit with a "dummy" BO, and get back "constraints", which you can feed into the allocator
<emersion> getting back constraints instead of "it may work, if you're lucky"
<emersion> is the important part
<pinchartl> that's about allocation, to find out how to allocate BOs (and also pick a pixel format, and modifiers) that work cross-device
<pinchartl> it's a missing component too, but that's not what I'm after here
<emersion> you're after a way to check whether a KMS configuration is supported
<emersion> and the driver might need a real BO to give an answer
<emersion> constraints solve this issue
<pinchartl> of course, that proposal would introduce a dummy BO that could then most likely also be used for testing composition use cases
<pinchartl> no, I disagree
<pinchartl> the proposal passes a dummy BO to an atomic test, and the driver returns constraints
<pinchartl> that's orthogonal to the issue of testing if scaling is supported
JohnnyonFlame has joined #dri-devel
<emersion> what if scaling is supported only for 16-byte aligned BOs?
<emersion> what would the dummy BO test-commit return, true or false?
<emersion> returning "it works under these buffer constraints" fixes that issue
<pinchartl> it's an additional problem that has to be handled, but it's not the same problem
<emersion> anyway, why do you need to know before-hand?
<clever> emersion: for some hardware (rpi), the scanout doesnt have any special alignment requirements that i know of, but the BO must be physically contiguous, and within the lower 1gig of the physical space
<emersion> if it doesn't work, you need a fallback
<emersion> which means you might as well wait to get a BO and see if you can use KMS or not
<pinchartl> today you can't even test if it works or not, that's hardly a fallback :-)
<emersion> the fallback is compositing via GL or Vulkan
<emersion> doing the scaling without KMS
<pinchartl> my platform has no GPU I can use
<pinchartl> and if KMS can't do it, I'll error out
<emersion> ah, embedded
<pinchartl> but I want to know *before* I get access to an FB
<pinchartl> the two issues are related. we may conclude that we need to solve both because it's too dangerous to solve the composition test only and leave the BO problem for later, we may then get stuck
fab has joined #dri-devel
<pinchartl> I can't tell if we have to bundle the two problems because of that, or if we can solve the composition test first in a way that gives us reasonable confidence that it won't hinder solving the BO problem
<pinchartl> to put it differently, is it acceptable to give applications a test API that does not guarantee the same commit with a real BO will be accepted ? I think it would be quite useful on its own on many embedded platforms
<emersion> i agree that small steps are best, and a "no definitely not" / "maybe" test API would be better than nothing
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<pinchartl> sounds like we have an endless amount of work to do :-)
<pinchartl> to give some context
<pinchartl> I'm working on an application that captures from a camera and display on a KMS plane, with zero copy
<pinchartl> the camera can capture in different resolutions
<pinchartl> and I'd like to test what resolutions can be supported with full screen display
<pinchartl> as I can then pick an appropriate one
<pinchartl> if I have to allocate BOs just for testing, for every different resolution, that gets very expensive
<emersion> hm, out of curiosity, would it be possible to allocate with the largest resolution, then create multiple FBs with smaller sizes?
<emersion> from the same large BO
<pinchartl> that would be fairly impractical (but one may argue that's because of the whole userspace stack design)
<pinchartl> it *may* be possible, but that would incur a performance impact in any case, as I'd have to allocate large buffers, to then free them and reallocate smaller ones. that takes time and would be best avoided
<pinchartl> (of course I could also keep the large buffers regardless of the selected camera capture resolution, but then I'd waste memory)
<pinchartl> it's "fun" to deal with systems that have 256MB of RAM :-)
* pinchartl remembers the time when he had to deal with Linux systems with 16MB of RAM
<pinchartl> there was fortunately no video there
<clever> i just realized a tricky the pi3 does, the MMIO is at the top 16mb of the lower 1gig
<clever> and if you set gpu_mem=16 (the smallest it can do), the firmware is also in the top 16mb of the lower 1gig...
<clever> i suspect the firmware is entirely covered up by the mmio window
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
nchery is now known as Guest7314
nchery has joined #dri-devel
Guest7314 has quit [Ping timeout: 480 seconds]
nchery is now known as Guest7315
nchery has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Guest7315 has quit [Ping timeout: 480 seconds]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
fab has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
sravn has joined #dri-devel
lygstate has quit [Read error: Connection reset by peer]
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: Bouncer restarting]
lemonzest has quit [Quit: WeeChat 3.5]
Lyude has joined #dri-devel
kts has joined #dri-devel
nchery is now known as Guest7323
nchery has joined #dri-devel
Guest7323 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
QwertyChouskie has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
reduz__ has quit [Read error: Connection reset by peer]
reduz__ has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
dschuermann has quit [Read error: Connection reset by peer]
dschuermann has joined #dri-devel
nchery is now known as Guest7326
nchery has joined #dri-devel
Guest7326 has quit [Ping timeout: 480 seconds]
<Frogging101> airlied: I actually can't find anywhere that we call into addrlib aside from src/amd/common/ac_surface.c
<bnieuwenhuizen> Frogging101: see stuff like AddrComputeSurfaceInfo
<Frogging101> yes, we call that in ac_surface.c to populate surface fields
<bnieuwenhuizen> that is a call into addrlib?
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
fxkamd has quit []
<Frogging101> bnieuwenhuizen: Yes. However, I would be adding this to src/amd/vulkan/radv_meta_bufimage.c. I could pull in the addrlib handle from cmd_buffer->device->ws->addrlib. I'm just saying this might be crossing areas of concern a bit, and this would be the first time
<Frogging101> (the addrlib handle is stored in the radv_amdgpu_winsys structure)
<bnieuwenhuizen> Frogging101: what are you doing?
<Frogging101> I need to do what addrlib's HwlComputeNonBlockCompressedView function does, in radv. The function calculates new mip level parameters and extents for the image view in order to work around the hardware's bad mipmap degradation
nchery has quit [Read error: Connection reset by peer]
<bnieuwenhuizen> oh they added a function?
<bnieuwenhuizen> did they do that for gfx9 too?
<Frogging101> They only do this for gfx10. For gfx9 they do another copy after the regular one to copy the blocks that the regular copy didn't get
<Frogging101> For gfx10 they adjust the descriptor. For gfx9 they do a second round of copying
<bnieuwenhuizen> so recommended way would be to add another function in the winsys
<bnieuwenhuizen> longer term we might want to extract the addrlib handle from the winsys and only put the initialization in the winsys
<Frogging101> I would need to feed it parameters from the image view that is created during the meta copy path
<bnieuwenhuizen> just format and base mip, right?
<bnieuwenhuizen> and slice apparently
<Frogging101> The selected mip too, not just the base mip
<bnieuwenhuizen> base mip of the view is the selected mip in this case, no?
<Frogging101> Yes
<Frogging101> It needs to be called at a point that we know the selected mip, anyway
QwertyChouskie has quit [Remote host closed the connection]
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<bnieuwenhuizen> hmm, reading the code one thing to watch out for is that that code doesn't support 3d images, not sure what we support offhand
<Frogging101> actualExtentElements is, I believe, equivalent to our u.gfx9.base_mip_width/height
fab has quit [Quit: fab]
<Frogging101> bnieuwenhuizen: I also wanted to use ComputeSurfaceAddrFromCoord for the GFX9/"second copy" case. PAL uses it to calculate the memory offset into the image to copy from/to
<Frogging101> That's another addrlib function
<Frogging101> Maybe I'll implement the workarounds in whatever way is easiest and then we can talk about what the best place to put stuff is
Haaninjo has quit [Quit: Ex-Chat]
Duke`` has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
jewins has joined #dri-devel
pcercuei has quit [Quit: dodo]
alarumbe has quit [Remote host closed the connection]
alarumbe has joined #dri-devel
jernej_ has joined #dri-devel
jernej has joined #dri-devel
<Frogging101> Does piglit test Vulkan or just OpenGL?
leandrohrb11 has joined #dri-devel
lcn_ has joined #dri-devel
enunes- has joined #dri-devel
padovan7 has joined #dri-devel
ds- has joined #dri-devel
<airlied> Frogging101: opengl, though not sure if it has some interop tests
<airlied> but mostly we use vulkan cts for vulkan
svenpeter has joined #dri-devel
g0b_ has joined #dri-devel
mriesch_ has joined #dri-devel
pochu_ has joined #dri-devel
tjaalton_ has joined #dri-devel
mmind00_ has joined #dri-devel
HdkR_ has joined #dri-devel
<Frogging101> Via piglit or by itself? Apparently piglit can run it
jernej_ has quit [reticulum.oftc.net kinetic.oftc.net]
TMM has quit [reticulum.oftc.net kinetic.oftc.net]
enunes has quit [reticulum.oftc.net kinetic.oftc.net]
feaneron has quit [reticulum.oftc.net kinetic.oftc.net]
HdkR has quit [reticulum.oftc.net kinetic.oftc.net]
tleydxdy has quit [reticulum.oftc.net kinetic.oftc.net]
mlankhorst_ has quit [reticulum.oftc.net kinetic.oftc.net]
ana has quit [reticulum.oftc.net kinetic.oftc.net]
leandrohrb1 has quit [reticulum.oftc.net kinetic.oftc.net]
vsyrjala has quit [reticulum.oftc.net kinetic.oftc.net]
bnieuwenhuizen has quit [reticulum.oftc.net kinetic.oftc.net]
Akari has quit [reticulum.oftc.net kinetic.oftc.net]
mriesch has quit [reticulum.oftc.net kinetic.oftc.net]
Terman has quit [reticulum.oftc.net kinetic.oftc.net]
g0b has quit [reticulum.oftc.net kinetic.oftc.net]
vup has quit [reticulum.oftc.net kinetic.oftc.net]
pq has quit [reticulum.oftc.net kinetic.oftc.net]
APic has quit [reticulum.oftc.net kinetic.oftc.net]
milek7 has quit [reticulum.oftc.net kinetic.oftc.net]
sven has quit [reticulum.oftc.net kinetic.oftc.net]
kunal_10185[m] has quit [reticulum.oftc.net kinetic.oftc.net]
mauld has quit [reticulum.oftc.net kinetic.oftc.net]
eyearesee has quit [reticulum.oftc.net kinetic.oftc.net]
bnieuwenhuizen_ has joined #dri-devel
heat has quit [charon.oftc.net helix.oftc.net]
adavy has quit [charon.oftc.net helix.oftc.net]
ppascher has quit [charon.oftc.net helix.oftc.net]
sul has quit [charon.oftc.net helix.oftc.net]
pendingchaos has quit [charon.oftc.net helix.oftc.net]
bbrezillon has quit [charon.oftc.net helix.oftc.net]
columbarius has quit [charon.oftc.net helix.oftc.net]
Emantor has quit [charon.oftc.net helix.oftc.net]
digetx has quit [charon.oftc.net helix.oftc.net]
mwk has quit [charon.oftc.net helix.oftc.net]
pochu has quit [charon.oftc.net helix.oftc.net]
minecrell has quit [charon.oftc.net helix.oftc.net]
cleverca22[m] has quit [charon.oftc.net helix.oftc.net]
r[m] has quit [charon.oftc.net helix.oftc.net]
ds` has quit [charon.oftc.net helix.oftc.net]
ella-0[m] has quit [charon.oftc.net helix.oftc.net]
qyliss_ has quit [charon.oftc.net helix.oftc.net]
kmn has quit [charon.oftc.net helix.oftc.net]
Venemo has quit [charon.oftc.net helix.oftc.net]
kbingham has quit [charon.oftc.net helix.oftc.net]
sravn has quit [charon.oftc.net helix.oftc.net]
lplc has quit [charon.oftc.net helix.oftc.net]
JosExpsito[m] has quit [charon.oftc.net helix.oftc.net]
kallisti5[m] has quit [charon.oftc.net helix.oftc.net]
jasuarez has quit [charon.oftc.net helix.oftc.net]
ambasta[m] has quit [charon.oftc.net helix.oftc.net]
Mershl[m] has quit [charon.oftc.net helix.oftc.net]
cwfitzgerald[m] has quit [charon.oftc.net helix.oftc.net]
jenatali has quit [charon.oftc.net helix.oftc.net]
gagallo7[m] has quit [charon.oftc.net helix.oftc.net]
doras has quit [charon.oftc.net helix.oftc.net]
Guest6845 has quit [charon.oftc.net helix.oftc.net]
kusma has quit [charon.oftc.net helix.oftc.net]
zzoon2627thholiday[m] has quit [charon.oftc.net helix.oftc.net]
turol has quit [charon.oftc.net helix.oftc.net]
pH5 has quit [charon.oftc.net helix.oftc.net]
rawoul has quit [charon.oftc.net helix.oftc.net]
marcan has quit [charon.oftc.net helix.oftc.net]
pepp has quit [charon.oftc.net helix.oftc.net]
bl4ckb0ne has quit [charon.oftc.net helix.oftc.net]
haasn` has quit [charon.oftc.net helix.oftc.net]
V has quit [charon.oftc.net helix.oftc.net]
gruetze_ has quit [charon.oftc.net helix.oftc.net]
tagr_ has quit [charon.oftc.net helix.oftc.net]
q66 has quit [charon.oftc.net helix.oftc.net]
jcristau_ has quit [charon.oftc.net helix.oftc.net]
hakzsam_ has quit [charon.oftc.net helix.oftc.net]
kj_ has quit [charon.oftc.net helix.oftc.net]
cazzacarna has quit [charon.oftc.net helix.oftc.net]
nielsdg has quit [charon.oftc.net helix.oftc.net]
dcbaker has quit [charon.oftc.net helix.oftc.net]
CounterPillow_ has quit [charon.oftc.net helix.oftc.net]
Koniiiik_ has quit [charon.oftc.net helix.oftc.net]
Adrinael has quit [charon.oftc.net helix.oftc.net]
gio_ has quit [charon.oftc.net helix.oftc.net]
tonyk has quit [charon.oftc.net helix.oftc.net]
tales-aparecida has quit [charon.oftc.net helix.oftc.net]
calebccff_ has quit [charon.oftc.net helix.oftc.net]
ptrc has quit [charon.oftc.net helix.oftc.net]
bgs_ has quit [charon.oftc.net helix.oftc.net]
urja has quit [charon.oftc.net helix.oftc.net]
lanodan has quit [charon.oftc.net helix.oftc.net]
Stary has quit [charon.oftc.net helix.oftc.net]
morphis has quit [charon.oftc.net helix.oftc.net]
mwalle has quit [charon.oftc.net helix.oftc.net]
glehmann has quit [charon.oftc.net helix.oftc.net]
DPA has quit [charon.oftc.net helix.oftc.net]
yoslin has quit [charon.oftc.net helix.oftc.net]
hikiko has quit [charon.oftc.net helix.oftc.net]
dv_ has quit [charon.oftc.net helix.oftc.net]
Prf_Jakob has quit [charon.oftc.net helix.oftc.net]
loki_val has quit [charon.oftc.net helix.oftc.net]
glennk has quit [charon.oftc.net helix.oftc.net]
gallo2 has quit [charon.oftc.net helix.oftc.net]
BobBeck has quit [charon.oftc.net helix.oftc.net]
AlexisHernndezGuzmn[m] has quit [charon.oftc.net helix.oftc.net]
Thaodan has quit [charon.oftc.net helix.oftc.net]
mauld_ has joined #dri-devel
padovan7 has quit [Read error: Connection reset by peer]
mupuf_ has joined #dri-devel
MrCooper_ has joined #dri-devel
V_ has joined #dri-devel
haagch_ has joined #dri-devel
MrCooper_ has quit [Remote host closed the connection]
MrCooper_ has joined #dri-devel
haasn has joined #dri-devel
lcn_ is now known as lcn
lcn has quit [Remote host closed the connection]
yoslin has joined #dri-devel
q66 has joined #dri-devel
CME has quit [Read error: Connection reset by peer]
MrCooper_ has quit [Read error: Connection reset by peer]
jcristau has joined #dri-devel
bl4ckb0ne has joined #dri-devel
mwalle has joined #dri-devel
ptrc has joined #dri-devel
Lynne has joined #dri-devel
lanodan has joined #dri-devel
CounterPillow has joined #dri-devel
MrCooper_ has joined #dri-devel
mupuf_ has quit [Remote host closed the connection]
Emantor has joined #dri-devel