<daniels>
KunalAgarwal[m]: gbm_bo_get_fd_for_plane() was added in Mesa 20.x - so either you're using an older version of Mesa, or you're using GBM from a different graphics driver which doesn't yet have that support
tursulin has quit [Read error: Connection reset by peer]
adarshgm has quit [Ping timeout: 480 seconds]
<KunalAgarwal[m]>
I have Mesa 20.3.5
tursulin has joined #dri-devel
ahajda has joined #dri-devel
<daniels>
ah sorry, I read the date wrong - it looks like it was introduced in 21.1.0
<KunalAgarwal[m]>
Ok so looks like updating it would work, thanks
<daniels>
np
pq has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
<daniels>
ah, Raspbian ... please get support from the RPi forums or something
<KunalAgarwal[m]>
ok thanks
fahien has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
Akari has quit [Quit: segmentation fault (core dumped)]
heat has joined #dri-devel
bmodem has joined #dri-devel
Akari has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
ajax has joined #dri-devel
bmodem has quit []
<agd5f>
mauld, done.
JohnnyonF has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<mauld>
agd5f: thanks
fxkamd has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
LexSfX has quit []
jewins has joined #dri-devel
LexSfX has joined #dri-devel
rasterman has joined #dri-devel
kts has joined #dri-devel
sdutt has joined #dri-devel
<bl4ckb0ne>
does GL_EXT_memory_object defines how to handle cubemaps? im getting GL_INVALID_OPERATION (immutable texture) when trying to fill it
Duke`` has joined #dri-devel
<jekstrand>
jenatali: So... my foreach macro destroyed Intel CI last night. :-/ New version incoming once I verify it generates the same code with both GCC and clang with -O2.
<jenatali>
jekstrand: :O how did it destroy it?
<jekstrand>
jenatali: GCC with -O2 and debug enabled didn't handle me modifying a variable declared const. :-/
<jekstrand>
Which is, in retrospect, totally fair.
<jenatali>
Ah, valid
<jekstrand>
I'm still confused as to exactly how that fail happened though because the blow up wasn't on modifying a const thing
<jenatali>
Cool, well I'll keep an eye out for it
<jenatali>
I mean, you triggered UB I guess, at which point the compiler can do whatever it wants, right?
<jekstrand>
There may be something busted with const struct initializers in a variable declaration list with multiple variables. It was weird.
<jekstrand>
Yeah....
<jekstrand>
Really, what screwed me over was C syntax for multiple variable declarations in one line. But I found a workaround. :)
nchery has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
MrCooper has quit [Remote host closed the connection]
<jekstrand>
jenatali: Does the windows VS build in CI build dozen?
kts has quit [Ping timeout: 480 seconds]
<jenatali>
Yep
<jekstrand>
Cool
<jenatali>
Even runs tests on it
<jekstrand>
:D
tursulin has quit [Ping timeout: 480 seconds]
<jekstrand>
I've tested locally with GCC and clang and I think we're good there. I've kicked it to Intel CI.
<jenatali>
Cool
<jekstrand>
But one of the changes makes the vk_foreach_struct() macro compile-fail if it's const so you have to use vk_foreach_struct_const() which is a good thing but it means touching lots of drivers.
<pq>
just don't do multiple variable declarations in a single statement. Remember how e.g. * associates in int* a, b; ;-)
<jekstrand>
Yeah, I'm aware of the * problems.
<pq>
I don't even know how const associates
<jekstrand>
It gets more fun with const. :)
<jekstrand>
In any case, I now have two for loops to avoid the double declaration. It works fine.
<jekstrand>
And, no, it doesn't break break and continue. I thought about that. :D
<jenatali>
This would be so much simpler in C++ with a functor/lambda that gets called on each iteration instead of preprocessor nonsense, IMO
<jenatali>
But I guess it's really just different for people who are used to reading different things
<jekstrand>
Yeah. Really, anything that lets you hide some temporary variable space would do the trick.
<jenatali>
Iteration macros are cool because they let you declare a loop body and have it work, but the amount of complexity you can use in that iteration is limited to what you can reasonably do with the preprocessor
<jenatali>
Oh well
<jekstrand>
jenatali: Not with my iterator struct double-for-loop trick. It can have arbitrary complexity. :D
<jenatali>
It's... pretty ugly though :P
<jenatali>
Especially since it technically makes all the indentation from then on wrong / off-by-one
<jekstrand>
Oh, I'm not gonna argue with that.
<jekstrand>
Indentation: I guess that depends on whether or not you're willing to consider it a single loop. It *should* act like one.
<jenatali>
Yeah, I just wouldn't be surprised if some IDE sees through the macro and wants to indent everything further
<jekstrand>
I wouldn't know. VIM isn't that smart. :P
<jekstrand>
The other option I thought of was to have a "void *vk_validate_pnext_chain(void *)" which does the loop check walk and run that before each for loop
<jekstrand>
But then it really is slower in debug builds because you have to walk the whole list in advance every time.
<karolherbst>
ehhh..... why is zink loading with glamor :(
<karolherbst>
I think something broke starting X recently
mbrost has joined #dri-devel
adarshgm has joined #dri-devel
<karolherbst>
ohh mhh.. maybe the reason is that I don't build zink
<karolherbst>
nvm... it's something else
MrCooper has joined #dri-devel
<jekstrand>
dj-death: Do you want to re-review my horrible pnext iterator?
<jekstrand>
I don't want to gross out too many people but you reviewed it the first time around.
<jekstrand>
jenatali: There are so many ways C++ would make that all better...
<jenatali>
Yep
<jekstrand>
jenatali: For one, I'd probably just write an iterator class following STL rules.
<jenatali>
Oh that works
<jekstrand>
But, alas.
<karolherbst>
why must it be so painful to use your local GL build over the system one :(
<jekstrand>
I really wish there were a form of for loop in C which let you declare multiple types of things.
<jenatali>
jekstrand: Hiding the brackets with an end macro instead of having the caller declare the brackets would also solve it. Then you can just declare your variables in a new scope
<karolherbst>
why is X loading _both_ the system one and my local one :(
<jekstrand>
jenatali: Yeah, but that looks uglier. :(
<jenatali>
Yeah I agree
<jenatali>
Also too much churn to change at this point
<jekstrand>
Much
Major_Biscuit has quit []
<ajax>
karolherbst: because xserver still open-codes its own dri loader instead of just being an egl client, iirc
<karolherbst>
:(
abws has joined #dri-devel
<ajax>
there's patches!
<karolherbst>
so it simply uses "hardcoded" paths with no option to overwrite those?
<ajax>
it should honor LIBDL_DRIVERS_PATH if it's not setuid
<jekstrand>
Oh, yeah, using a custom driver with X is super hard. If your system driver is good enough for X, everything else is easy
kts has joined #dri-devel
<karolherbst>
jekstrand: well.. I want to enable GL on Ampere :)
<karolherbst>
ajax: I set that!
<jekstrand>
karolherbst: Sure
<jekstrand>
karolherbst: I figured
<ajax>
but if you're Xorg and you're not careful then you're setuid
<karolherbst>
seems like past me was smarter than present me
srslypascal is now known as Guest5476
srslypascal has joined #dri-devel
<alyssa>
I'm admittedly unsure how to get around Ekstrand's Rule
<karolherbst>
depends on what you want to achieve :P
<alyssa>
for the nir_search thing
<karolherbst>
I think for nir_search it's okay if an undef value matches any constant
<alyssa>
Ekstrand's Rule states that if anyone other than jekstrand and cwabbott working together touches nir_search, they will break nir_search
<karolherbst>
that's a different problem than optimization operations mixing inputs
<karolherbst>
alyssa: I assume there is a load_const check somewhere :P
<karolherbst>
probably multiple ones
<karolherbst>
you could try to fiddle with that
<alyssa>
yep
<karolherbst>
shouldn't be toooooo risky
<karolherbst>
the big question which remains is, what to do with opts who do different things depending on the constant
<karolherbst>
should the one generating better code just be moved up?
<alyssa>
yeah, I think so
<alyssa>
that's what we do already in panfrost etc
<alyssa>
opt_undef first, then lower_undef_to_zero and opt_algebraic
<jekstrand>
karolherbst: What are we doing?
<jekstrand>
You two are scaring me. :P
<karolherbst>
jekstrand: matching undefs with any constant
<alyssa>
jekstrand: Teaching nir_search to match undef for '#0' specifically
<alyssa>
karolherbst: no, with 0 specifically
<karolherbst>
hey
<karolherbst>
any is more fun!
<alyssa>
I don't know that any is valid
<karolherbst>
why not?
<karolherbst>
think about it this way
<karolherbst>
if (undef) ...
<karolherbst>
it's more likely that undef is not 0 in the end :P
<karolherbst>
it's undef, it can be anything
Guest5476 has quit [Ping timeout: 480 seconds]
<alyssa>
but it's *one* thing
<alyssa>
suppose we hae two algebraic rules:
<alyssa>
a + 0 -> a
<alyssa>
a * 1 -> a
<karolherbst>
it's a quantum value, it's everything at the same time until you look at it :P
<alyssa>
and no other rules
<alyssa>
and then we have the program:
<alyssa>
a = undef; x = a + b; y = a * b
<alyssa>
if a is 0, then x = b and y = 0
<HdkR>
Oop, found a game that takes down the entire system
<alyssa>
if a is 1, then x = b + 1 and y = b
<karolherbst>
alyssa: nah...
<alyssa>
those are the valid combinations of x/y values
<karolherbst>
x = b and y = b :P
<jekstrand>
alyssa: You're quickly getting into poison/freeze territory
<alyssa>
jekstrand: Delightful.
<jekstrand>
Not sure if you're familiar with that?
<alyssa>
I've heard of it, don't know the details
<karolherbst>
although I think one undef has to keep being one value though
<karolherbst>
otherwise it's too much of a mess
<jekstrand>
It's a concept recently introduced to LLVM (as in the last couple years) and people are trying to stick in SPIR-V.
<jekstrand>
Basically, a poison value can be anything at any time and can even randomly change over time.
<jekstrand>
With a poison value, what you described would be a correc compilation.
<karolherbst>
and freeze is you assign a specific value to that anything one? :P
<jekstrand>
Then there's a "freeze" intrinsic which is logically a no-op except that it does have a value and that value never changes, you just don't know what it is.
<karolherbst>
"super"
<jekstrand>
If you freeze a well-defined value, it doesn't do anything.
<jekstrand>
It's just the original value.
danvet has quit [Ping timeout: 480 seconds]
<cwabbott>
jekstrand: actually what you're describing for poison is undef
<jekstrand>
cwabbott: ?
<jekstrand>
Am I missing how poison works?
<cwabbott>
poison is even stronger, it "poisons" anything
<jekstrand>
I think poison also has the semantics that any operation on poison is poison like NaN
rkanwal has joined #dri-devel
<jekstrand>
^^
<cwabbott>
so, poison & 0 -> posion
<jekstrand>
Right
<cwabbott>
whereas I think of undef as something that can have a different value each time you read it
<jekstrand>
Yeah.
<cwabbott>
also branching on poison is undefined behavior iirc
<jekstrand>
So you have three levels: Poison, Undef, and freeze(anything)
* alyssa
googling this but just getting information about antifreeze poisoning
<jekstrand>
Poison destroys anything it touches, undef may be any value at any time, and freeze() of either poison or undef gives you a value, you just don't know what it is.
<jekstrand>
lol
<karolherbst>
"fun"
lynxeye has quit [Quit: Leaving.]
<cwabbott>
anyway, I've definitely thought before about making undef match any constant
<cwabbott>
it would be valid
<karolherbst>
cwabbott: I think it would be a bit strange if you match different constants to the same undef value
<cwabbott>
karolherbst: well, that's strange but it is what undef means
<cwabbott>
it has to be that way so that RA doesn't have to make undef values live
<alyssa>
wait, so nir's ssa_undef is Undef and not Freeze? but also not Poison?
<cwabbott>
yes, it's Undef
<karolherbst>
ohh sure, in RA that's fine, I am just thinking from a logical perspective if program code out of the sudden behaves in strange ways
<karolherbst>
like a = undef; b = a + 1; c = a + 2; if (b == c) { // branch taken because undef matches any constant }...
<alyssa>
cwabbott: jekstrand previously gave the evil code "(undef | 0xffff) | 0xffff0000". With poison semantics, that equals Poison. With freeze semantics, that equals 0xffffffff. With undef, I guess this also equals 0xffffffff?
<karolherbst>
althought that probably optimized to b = 1 and c = 2
<karolherbst>
*optimizes
<karolherbst>
but I am sure there are more obvious examples where it can really do odd things
<jekstrand>
alyssa: With undef, it's still 0xffffffff because the undef is only read once
<cwabbott>
that's the whole point of undef though -- allowing you to do more sneaky things like this on code that's probably dead
<alyssa>
jekstrand: right okay
<alyssa>
To make sure I understand the distinction, for `x = <some undef>; y = x - x`, y is 0 with Freeze semantics, whatever the optimizer feels like with Undef semantics, and explicitly Poison with Poison semantics?
<cwabbott>
alyssa: technically it would be Undef with Undef semantics, but yes
<cwabbott>
and Freeze is actually an op that takes an input
<alyssa>
ok, I think that makes sense
<cwabbott>
it "stops" the non-determinism
<cwabbott>
so if you're talking about Freeze(Undef) or Freeze(Poison), then yes it's 0
<alyssa>
ahh, ok
<alyssa>
so I guess "undef matches any constant" would be valid in nir_search after all, because ssa_undef is Undef and not Freeze(Undef) ... I guess we should be doing that and then hw drivers can stop using lower_undef_to_zero without regressing code quality
<karolherbst>
I am mostly wondering if there is code out there, that relies on undef being "constant" and not something which changes its value out of the sudden
<karolherbst>
I am sure there is tons of C code which does :P
<alyssa>
nod
<karolherbst>
which I think is the main idea behind freeze, so you make sure that the undef value is indeed "constant"
<jekstrand>
There's a lot of debate about what should happen if you have an uninitialized variable and you use it twice. Is it really undef where it can be different things? Or did it get a value when created and you just don't know what that is?
<ajax>
karolherbst: make a tarball (git-export works), edit mesa.spec to point to it and (probably) not apply any patches, rpmbuild -bs *.spec && mock -r fedora-36-x86_64 *.src.rpm
<jekstrand>
I think it's UB in C/C++ but people are trying to tighten things.
<jekstrand>
And poison/freeze is way more precise and easier to define than undef
<karolherbst>
jekstrand: given that people used (and I hope it's _used_ not _use_) for seeding crypto algos, I think C people rely on it having an assigned value :)
<karolherbst>
*it
<karolherbst>
like openssl I think had this bug once, where making all undef 0 broke security....
rkanwal has quit [Ping timeout: 480 seconds]
<ajax>
that was debian bzero'ing an initialization vector that openssl was hoping would have random data in it
<karolherbst>
ahhh, right
<karolherbst>
well
<karolherbst>
it's still an openssl bug :P
<ajax>
though, it was expecting _the same_ random data each time
<ajax>
random and not modified by the act of reading it
<karolherbst>
yeah
<karolherbst>
if that random data would change it would break code hard
<jekstrand>
You should never assume stack data is random. That's really easy to manipulate.
<karolherbst>
anyway...
<karolherbst>
devs doing shitty things with undef values :D
<karolherbst>
jekstrand: no shit :P
<ajax>
jekstrand: yeah yeah. this was already down in the "somehow we think we don't have /dev/urandom" path, iirc, which itself getting hit was already a bug, ...
<karolherbst>
it's was dump code to begin with
<karolherbst>
*dumb
<jekstrand>
In any case, I'm not sure I actually want algebraic to get rid of undefs.
<ajax>
and, as always, anything in openssl is best approach with a butane torch at minimum
<jekstrand>
Getting rid of them too early and turning them into "real" things means that our logic which does stuff like merge phi sources which are all undef together will break.
<karolherbst>
apparently openssl maintainers still push patches last minute without reviews right before releases... so....
<jekstrand>
That's part of why poison is so much better. You can optimize it without actually getting rid of poison.
abws has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
<alyssa>
jekstrand: what's the problem with optimizing x + undef -> x?
<jekstrand>
alyssa: Hrm... Maybe that's ok. But optimizing undef -> 0 too early is problematic
<jekstrand>
It can make your phi webs more complicated
<alyssa>
yeah, that's why I want to stop doing it in panfrost
<alyssa>
but not running undef_to_zero would regress code quality due to the pile of algebraic opts it enables
<alyssa>
hence my original question about nir_search
<jekstrand>
Oh
<jekstrand>
How much does math on undef values come up? That seems like a thing that ought to be rare...
<alyssa>
cbe24a0e9c5 ("broadcom/compiler: use nir_lower_undef_to_zero")
<jekstrand>
?
<alyssa>
i'm looking for the panfrost stats
<jekstrand>
kk
<alyssa>
oh, maybe I never posted stats
<jekstrand>
Those broadcom stats seem wrong...
<alyssa>
qwhy?
<jekstrand>
NVM, they're probably fine. It only affects ~300 programs and given by how much, they're probably wrong.
<jekstrand>
(The programs, not the stats)
<alyssa>
ah
ngcortes has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<airlied>
jekstrand: lvp isnt special, all the other drivers are just
<jekstrand>
airlied: Careful how you finish that. :P
* airlied
leaves it to the reader :-)
ybogdano has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
janesma has joined #dri-devel
janesma has quit [Quit: Leaving]
rasterman has joined #dri-devel
apinheiro has joined #dri-devel
JoniSt has joined #dri-devel
<JoniSt>
zmike: !17597 ignores TC_MAX_SUBDATA_MERGE_BYTES when merging exactly 2 subdata calls, is that on purpose? (I kinda doubt it?) I can try and simplify the logic in there a bit too if you like
<zmike>
I might just delete that define altogether since I only added it to fix a bug in an earlier version
<JoniSt>
Ah :)
<zmike>
but then maybe not idk
<JoniSt>
The huge if statement at the beginning can also probably be dropped, I can try and do that if you want
<zmike>
the idea is to mimic draw merging so that this has a familiar feel to it
<JoniSt>
My suggestion would be to always enter the "check for mergeable" loop and fall back to regular subdata if there's only that 1 subdata call
alyssa has left #dri-devel [#dri-devel]
pcercuei has quit [Read error: Connection reset by peer]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
nchery has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<bl4ckb0ne>
would it be possible to use the vk-gl interop to upload a cubemap texture from opengl to vulkan?
<bl4ckb0ne>
im hitting immutable texture errors when calling glTexImage2D to load the faces
<bl4ckb0ne>
i haven't seen anything in the spec regarding glTextureStorageMem2DEXT and cubemaps
<bl4ckb0ne>
if I understand correctly the cubemap texture has no storage itself but makes some for the 6 faces
<bl4ckb0ne>
or am I better off with a GL_TEXTURE_2D_ARRAY and 6 layers?
YuGiOhJCJ has joined #dri-devel
<JoniSt>
The texture object becomes immutable as soon as you call glTextureStorageMem2DEXT. From that point on, it is associated with the backing Vulkan memory. glTexImage2D attempts to allocate *new* memory for the texture object, which simply isn't possible (and it would undo your memory import if it was possible)
<bl4ckb0ne>
so it wouldnt be possible to exchange a cubemap between the gl and vk
<bl4ckb0ne>
or i have to configure it (calling glTexImage2D) before calling glTextureStorageMem2DEXT
<JoniSt>
It should be possible, you just can't call glTexImage2D afterwards
<bl4ckb0ne>
im kinda blocked by openxr in my context, the image is configured before its being given to the user
gouchi has quit [Remote host closed the connection]
<JoniSt>
My guess would be that you have to glBindTexture(GL_TEXTURE_CUBE_MAP, tex); glTexStorageMem2DEXT(GL_TEXTURE_CUBE_MAP, /* stuff */);
<bl4ckb0ne>
yeah that's what the runtime does, before handing the texture id to the caller
<bl4ckb0ne>
ill try to go that way, might be easier to match with openxr
<JoniSt>
Doesn't that already do what you need? What are you using the glTexImage2D call for? To upload data into the texture?
<bl4ckb0ne>
yes
<JoniSt>
Ah, then the problem isn't that it's a cubemap, it's just that *any* texture shared between VK and GL is immutable
<JoniSt>
You'd have the same problem sharing a regular 2D texture
<bl4ckb0ne>
thats where Im blocked, the caller need to upload its texture
<bl4ckb0ne>
so there's really no way around that eh
<JoniSt>
Well, glTexStorage2D is equivalent to malloc+upload. You just want to upload, not malloc. So you just need a different function.
<JoniSt>
Been a while since I did GL application development, but let me look it up what that function was again
<bl4ckb0ne>
glTexSubImage2D iirc
<JoniSt>
Right! :P
<JoniSt>
Just call that instead of glTexImage2D and you should be good
<bl4ckb0ne>
so the glTextureStorageMem2DEXT already takes care of allocating 6 images?
<JoniSt>
I think you have to use TexStorage and not TextureStorage to actually get a cubemap, but yes
<JoniSt>
It should become a cubemap as soon as you glBindTexture(GL_TEXTURE_CUBE_MAP, tex)
<JoniSt>
Then you give it the Vulkan memory with glTexStorageMem2DEXT, at which point the texture becomes immutable, and finally upload pixels with glTexSubImage2D. Don't forget appropriate synchronization between GL and VK (you might need some fences, semaphores, and glFinish)
<bl4ckb0ne>
hm hitting segfaults
<bl4ckb0ne>
ill take a deeper look tomorrow
<bl4ckb0ne>
thanks!
<JoniSt>
You're welcome, but take my info with a grain of salt, it's been a while since I've done this stuff :)
<JoniSt>
And remember that GL isn't going to execute your commands immediately, GL drivers are free to delay forever unless you synchronize with the GL (fence/glFinish)
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
<jenatali>
The external objects extension defines a semaphore that you need to use for synchronizing, yeah
ybogdano has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
aswar002 has quit [Remote host closed the connection]
unerlige has quit [Remote host closed the connection]
mdnavare has quit [Remote host closed the connection]
rsripada_ has quit [Remote host closed the connection]
rsripada has quit [Remote host closed the connection]
nchery has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
shankaru has quit [Remote host closed the connection]
sdutt has quit [Remote host closed the connection]
Ryback_ has quit [Remote host closed the connection]
rsripada has joined #dri-devel
Ryback_ has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mattrope has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
jewins has quit [Remote host closed the connection]
ahajda has quit [Remote host closed the connection]
sdutt has joined #dri-devel
mbrost has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
lstrano has quit [Remote host closed the connection]
mattrope has joined #dri-devel
ngcortes has joined #dri-devel
ybogdano has joined #dri-devel
shankaru has joined #dri-devel
ahajda has joined #dri-devel
lstrano has joined #dri-devel
aswar002 has joined #dri-devel
rsripada_ has joined #dri-devel
unerlige has joined #dri-devel
OftenTimeConsuming is now known as Guest5494
OftenTimeConsuming has joined #dri-devel
mdnavare has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
rsripada has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
rsripada_ has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
shankaru has quit [Remote host closed the connection]
Guest5494 has quit [Remote host closed the connection]
rsripada has joined #dri-devel
sdutt has quit [Remote host closed the connection]
Ryback_ has quit [Remote host closed the connection]
mbrost has quit [Remote host closed the connection]
unerlige has quit [Remote host closed the connection]
mattrope has quit [Remote host closed the connection]
pzanoni has quit [Remote host closed the connection]
ramaling has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
lstrano has quit [Remote host closed the connection]
ahajda has quit [Remote host closed the connection]
ramaling has joined #dri-devel
pzanoni has joined #dri-devel
sdutt has joined #dri-devel
mbrost has joined #dri-devel
unerlige has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
lstrano has joined #dri-devel
mattrope has joined #dri-devel
ngcortes has joined #dri-devel
shankaru has joined #dri-devel
ybogdano has joined #dri-devel
Ryback_ has joined #dri-devel
ahajda has joined #dri-devel
rsripada_ has joined #dri-devel
danvet has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]