<mattst88>
I don't recall whether it works without the KVM in the mix. I think I tested that months ago, but I've just forgotten at this point
alatiera has quit [Ping timeout: 480 seconds]
<imirkin>
mattst88: based on the questions in the amazon page, the thing does sound a bit dodgy
<imirkin>
mattst88: "does it work with 4k monitors" -> "nope", despite the marketing materials explicitly saying yes?
<imirkin>
and they somehow manage not to support adapters, which is another indicator of dodginess
<imirkin>
"we do not support docking stations"
<imirkin>
you name it, they don't support it :)
shashank1202_ has joined #dri-devel
Lucretia has quit []
fcarrijo has joined #dri-devel
fcarrijo has quit []
nchery has quit [Quit: Leaving]
camus1 has joined #dri-devel
<mattst88>
imirkin: yeah :|
<mattst88>
seems to work fine after setting the monitors to DP1.1, so *shrug*
<mattst88>
KVMs are just generally awful though
camus has quit [Ping timeout: 480 seconds]
<mattst88>
my best guess is that the KVM attenuates the signal somewhat, and the bandwidth requirements of DP1.2 are greater than DP1.1
<mattst88>
and maybe the attenuation only sufficiently messes up the DP1.2 signal
<HdkR>
I have some KVMs which are just passthrough, so you have to use some /really/ good cables
<HdkR>
Otherwise flicker mess
<mattst88>
yeah, that's kind of what I was thinking as well, so I got some short (1m) cables that are VESA certified. unfortunately, still flickered
<HdkR>
I had to switch over to some fiber cables to make them less likely to flicker myself
Bhawan has quit []
jernej_ has quit []
jernej has joined #dri-devel
milek7 has quit [Remote host closed the connection]
milek7 has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
bbrezillon has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
<imirkin>
mattst88: DP 1.2 bandwidth requirement isn't any higher, and there's link training to ensure you use a stable freq
<imirkin>
DP 1.2 *can* do higher rates, but it doesn't have to
<mareko>
zmike: I think the way to go with a mega draw is to just let the driver parse tc_batch directly instead of inventing a complicated mega draw interface
boistordu has joined #dri-devel
Company has quit [Quit: Leaving]
mclasen has quit [Ping timeout: 480 seconds]
shashank1202_ has quit [Quit: Connection closed for inactivity]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
Daanct12 has joined #dri-devel
gpoo has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
Duke`` has joined #dri-devel
macromorgan is now known as Guest4076
macromorgan has joined #dri-devel
Guest4076 has quit [Read error: Connection reset by peer]
kenjigashu has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
kenjigashu has quit []
aravind has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit []
xlei_ has joined #dri-devel
xlei has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
kenjigashu has joined #dri-devel
itoral has joined #dri-devel
kenjigashu has quit []
Duke`` has quit [Ping timeout: 480 seconds]
zf has quit [Read error: Connection reset by peer]
<mareko>
do we have a NIR pass that groups independent texture opcodes such that there are no other instructions between them?
zf has joined #dri-devel
i-garrison has quit []
<mareko>
instead of: "load; use; load; use;", the idea is to do "load; load; use; use;"
zf` has joined #dri-devel
i-garrison has joined #dri-devel
Hi-Angel has joined #dri-devel
zf has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
unsolo_ has joined #dri-devel
zf has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
zf` has quit [Ping timeout: 480 seconds]
unsolo_ has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
zf has quit [Remote host closed the connection]
zf has joined #dri-devel
zf has quit []
zf has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
camus1 has joined #dri-devel
pnowack has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
zf has quit []
zf has joined #dri-devel
unsolo has joined #dri-devel
elongbug has joined #dri-devel
rasterman has joined #dri-devel
Venemo__ is now known as Venemo
<Venemo>
Just realized I wasn't authenticated...
<Venemo>
mareko: there exists a NIR scheduler, but we don't use it. I think pendingchaos tried it but it wasn't too good. The LLVM and ACO schedulers should do a good job at this
fxkamd has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
pjakobsson has joined #dri-devel
rgallaispou has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
<mareko>
LLVM doesn't do that
<mareko>
is there a helper that can tell whether nir_instr has no side effects? (is movable)
<mareko>
I guess I can copy instr_is_invariant
dongwonk has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
Lucretia has joined #dri-devel
zf` has joined #dri-devel
zf has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<cwabbott>
mareko: at least the ACO pre-RA scheduler will do that for you
<cwabbott>
something like that is the domain of the scheduler
<cwabbott>
if LLVM doesn't do that, ask one of your LLVM guys or help with the switch to ACO ;)
hansg has joined #dri-devel
mlankhorst has joined #dri-devel
camus has joined #dri-devel
mclasen has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
unsolo_ has joined #dri-devel
mairacanal has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
mairacanal has quit []
flacks has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
gpoo has joined #dri-devel
Company has joined #dri-devel
tango_ has quit [Read error: No route to host]
tango_ has joined #dri-devel
itoral has quit []
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
vivijim has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
unsolo_ has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
Peste_Bubonica has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
mairacanal has joined #dri-devel
mairacanal has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<zmike>
mareko: I was actually considering that something like that might be nice for various other things, like inlining multisample resolve blits for me
f11f12 has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
nchery has joined #dri-devel
ppascher has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
Bhawan has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Lucretia has quit []
Lucretia has joined #dri-devel
Duke`` has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Bhawan39 has joined #dri-devel
hansg has quit [Remote host closed the connection]
<imirkin>
zmike: it's definitely possible to have GL_DOUBLE vertex attribs in GL 3.0
<imirkin>
or rather
<imirkin>
to feed GL_DOUBLE data to float vertex attribs
<zmike>
I see
<imirkin>
almost no hw supports this, so double -> float happens on cpu somewhere
<imirkin>
i guess an argument could be made to feed it in as a plain double to the gpu and do the -> float conversion there. but you could end up with too many attribs, since it still only counts as a single slot
<zmike>
but if you advertise support for a 64bit vertex attrib format in gallium, does gallium assume your hw has that support or does it just enable the conversion
<imirkin>
64-bit attribs are different than what i just said
<imirkin>
that's where the double (or int64 or whatever) actually makes it all the way through to the shader unmolested
<imirkin>
in practice this gets lowered to 2x32 in st/mesa
<zmike>
I'm talking about 32bit shader inputs with 64bit attribs
<imirkin>
ok, that has nothing to do with the ext you're quoting then
<zmike>
well you started before I finished
<imirkin>
hehe ok. gave you 30s :p
<imirkin>
anyways, in gallium iirc that comes through as PIPE_FORMAT_R64*
<zmike>
the main spec allows passing 64bit through non *L* functions according to the charts in chapter 10
<zmike>
which seems to go entirely against the 64bit attrib spec
<imirkin>
mmmm
<imirkin>
let's have a read then
<zmike>
gallium does pass 64bit attribs through, except it's usually rewritten to 32bit attribs
<imirkin>
what you're saying about the main spec matches my understanding
<zmike>
it's very confusing
<imirkin>
you're confusing the format of the source data with the format of the attrib in the shader
<imirkin>
64-bit data + 64-bit attrib is a separate case from 64-bit data and 32-bit attrib
<imirkin>
in the first case, the data and attrib becomes 2x32
<imirkin>
in the second case, you get one attrib with PIPE_FORMAT_R64*
<zmike>
so if you don't use a *L* function then you get the actual 64bit attrib format
<imirkin>
yes, but it's a 32-bit shader var
<zmike>
I see
<imirkin>
so you lose the double precision
<imirkin>
it's just a way for the application to let GL worry about it
dviola has quit [Quit: WeeChat 3.3]
<imirkin>
where do you see that you can only feed GL_DOUBLE's into *L*?
<zmike>
so for such cases, when you get a 64bit format like that, you should be reading it as 32bit (i.e., only reading those bits) ?
<imirkin>
no
<imirkin>
you should be doing fp64 -> fp32
<zmike>
ok
<imirkin>
nouveau uses the translate module to do that.
<zmike>
thus if L is not used, GL_DOUBLE cannot be used
<imirkin>
where do you see that?
<zmike>
it's that whole paragraph
gouchi has joined #dri-devel
<zmike>
right at the top of overview
<imirkin>
look at issue #1
<imirkin>
overview is non-nomrative.
<imirkin>
check why the "L" variants were added in the first place.
<zmike>
this makes my head hurt
<zmike>
why would they say that in the spec if it's not actually true
<imirkin>
i don't see where in the overview they say that doubles must go through *L*
<imirkin>
but i'm only skimming
dviola has joined #dri-devel
<anholt>
yeah, I'm not seeing it either.
<anholt>
the overview also talks about the implicit 64-32 prior to the extension.
<imirkin>
they say that they're adding *L* variants to allow specifying 64-bit *attributes*, to distinguish from e.g. 64-bit data going into 32-bit attributes
<zmike>
maybe I'm just reading it wrong then
<imirkin>
anyways, it helps knowing what all exists when trying to understand this stuff
<imirkin>
one can easily jump to a wrong conclusion
<zmike>
every time I try to read GL specs I just miss vulkan that much more
<imirkin>
this is why i always hated doing piglits + core/driver impl of something -- i was just making sure it was workign the way i thought was right, which might not be the way it was intended
<imirkin>
zmike: it all takes some orientation. i can never figure anything out from vk specs
camus1 has joined #dri-devel
dongwonk has quit [Remote host closed the connection]
dongwonk has joined #dri-devel
<zmike>
I guess we're a matched set then
<imirkin>
zmike: btw, piglit for e.g. the GL 3.0 + GL_DOUBLE attrib thing is "draw-vertices -fbo -auto"
<zmike>
yep, that's what I'm looking at
<imirkin>
idiotic feature, if you ask me
<zmike>
doesn't seem that smart
<imirkin>
probably catering to some CAD programs? dunno
camus has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<imirkin>
(whenever i see a weird GL feature, i just assume some CAD program is to blame)
* zmike
has yet to run a CAD program
<imirkin>
(like 2-sided fill modes, edge flags, not to mention everyone's favorite -- render modes)
<ajax>
i will not rest until we have all of 1.5 + ARB_imaging accelerated with compute shaders or better
<imirkin>
ajax: maybe finally we'll have accum buffers
<ajax>
they're just a funny name for sint16, right?
ybogdano has quit [Remote host closed the connection]
<imirkin>
ajax: sounds not-wrong. i know quite little about them.
<imirkin>
except that there's literally 0 applications that use them
* ajax
sees a path including mesa-demos/src/redbook and stops himself
<imirkin>
there are piglit tests too
<imirkin>
i meant real applications
<ajax>
probably they exist for irix
<imirkin>
yeah
<imirkin>
and probably SGI hardware supported them
<imirkin>
like in Indy's or O2's or whatever
<ajax>
i think by the time that became a req'd render target in d3d we already had FBOs so why would you need them a) from the window system b) sized to the window
<imirkin>
why would you need them at all
<ajax>
dynamic range
<ajax>
same reason you'd want fp16, just, cheaper
Daanct12 has joined #dri-devel
<HdkR>
Does anything actually using ARB_imaging?
<ajax>
again, no
<HdkR>
I thought it was just the joke you get to bring up when GL is considered a good API :P
<HdkR>
Compat GL is my flavour of pain and suffering
<ajax>
this isn't about fixing some specific app, this is merely going for 100% completion as a point of, like, pride
dviola has quit [Quit: WeeChat 3.3]
Danct12 has quit [Ping timeout: 480 seconds]
tango_ has quit [Ping timeout: 480 seconds]
<HdkR>
Feels like one of those things that would be ultra low on the priority list. Just behind GL_NV_path_rendering
<imirkin>
ahaha
Daaanct12 has joined #dri-devel
<imirkin>
i think "stick eye with hot poker" is higher on that list than GL_NV_path_rendering
<ajax>
wow. i had managed to avoid reading NV_path_rendering somehow
Daaanct12 has quit []
<imirkin>
basically logo instead of glsl ;)
Danct12 has joined #dri-devel
<milek7>
SVG in GL?
Daanct12 has quit [Ping timeout: 480 seconds]
<imirkin>
and PS :)
<ajax>
and implicitly whatever the system font loader can load
rgallaispou has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
<imirkin>
i mean, it's a neat concept ... render SVG's on the GPU. but perhaps the GL driver is the wrong place to implement that? :)
<jenatali>
We implemented SVG in D2D for hardware-accelerated rendering back in Win8 or 8.1 I think
Hi-Angel has quit [Read error: No route to host]
xlei_ has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
xlei has joined #dri-devel
<imirkin>
jenatali: hopefully in the D2D library rather than the vendor-supplied portion?
<jenatali>
Yep
gpoo has quit [Ping timeout: 480 seconds]
<jenatali>
Implemented on top of D3D, rather than by a driver
<imirkin>
right. that makes sense
<imirkin>
which is what this NV_path_rendering should have been -- a small lib that makes use of GL to do things
dongwonk has quit [Ping timeout: 480 seconds]
dongwonk has joined #dri-devel
halfline[m] has joined #dri-devel
halfline is now known as enilflah
halfline[m] has quit []
halfline[m] has joined #dri-devel
halfline[m] has quit []
halfline[m] has joined #dri-devel
halfline[m] is now known as halfline
halfline has quit []
halfline has joined #dri-devel
<FLHerne>
to be fair, from the app-developer side NV_path_rendering is pretty convenient
<HdkR>
It would be convenient as a library as well ;)
<HdkR>
Obviously Nvidia wouldn't want to open that though
tango_ has joined #dri-devel
gpoo has joined #dri-devel
<milek7>
I think they said it was in driver due to performance?
<milek7>
"The 8-bit memory transactions during the stencil and cover steps can often run at memory bus saturating rates. Our OpenGL driver implementation makes use of a configurable front-end processor within the GPU—not otherwise accessible to applications—to transition quickly between the stencil step and cover step and back."
<HdkR>
If the performance couldn't be achieved as a library then there are now concerns about deficiencies in GL that should also have been rectified :D
X-Scale has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
FireBurn has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<dcbaker>
HdkR: you mean Vulkan? :D
<HdkR>
dcbaker: I don't see VK_NV_path_rendering yet :P
<imirkin>
don't give 'em ideas
<dcbaker>
Oh, i thought you meant, implement it as a library on top of Vulkan :)
<dcbaker>
Since GL is too slow
<agd5f>
imirkin, IIRC there were patches for render mode, but I don't think they ever got applied.
<imirkin>
agd5f: if you say so. i don't remember that. mareko talked about some ideas for doing it.
lemonzest has quit [Quit: WeeChat 3.2]
<agd5f>
imirkin, in mesa there was a hw_gl_select branch prior to the migration to gitlab
<mareko>
cwabbott: I'm reinventing that instruction scheduler in NIR, right now I just group all tex opcodes by moving everything else after the last tex or before the first tex in a block, but having something that handles indirections between tex would be nice
<Venemo>
mareko LLVM's AMDGPU backend runs a scheduler both before and after register allocation
<Venemo>
that said, there is a NIR scheduler which AFAIK isn't very good yet
<agd5f>
pepp, was involved as well it looks like
<mareko>
Venemo: LLVM doesn't do anything wrt grouping tex
<mareko>
I kinda need it today, and somethiing like that isn't gonna happen today in the LLVM world
gawin has joined #dri-devel
<Venemo>
Oh, I see
<Venemo>
Well, then the NIR scheduler may be what you want
<Venemo>
Or if you are looking to moving tex accross blocks, nir_opt_gcm is the hot stuff
<mareko>
the idea I have is to rank tex opcodes but the number of tex indirections within a block, and then group individual ranks, and move ALUs forward
<mareko>
*but=by
<mareko>
I have no clue how to use the NIR scheduler
<gawin>
maybe some garbage? the issue with textures (which is happening on r300g) is that some of them are red or transparent
sdutt has quit [Ping timeout: 480 seconds]
<gawin>
I can validate the "layer" of compiler, but "layer" with switches for hardware is kinda difficult topic for me (so sorry for some trivial questions)
<jenatali>
Hooray, I'm finally allowed to talk about Android stuff. Been super annoying to be flailing around with no idea what I'm doing and not being able to ask people
<FLHerne>
jenatali: Is there some announcement?
<jenatali>
FLHerne: Android apps on Win11 went out to Windows insiders last week
<robclark>
jenatali: so, do you find android cts-runner as annoying as I do? ;-)
<jenatali>
robclark: Actually haven't tried it yet, but I'm sure I will
<robclark>
ahh, lucky you
<FLHerne>
There've been so many years of people inventing layers to run MS APIs on Linux (ndiswrapper, samba, WINE, nine, case-insensitive filesystem hacks, ...)
camus has quit [Ping timeout: 480 seconds]
<FLHerne>
and now you guys suddenly want to emulate everyone else's
<HdkR>
It's a fancy new world we live in
pendingchaos has quit [Ping timeout: 480 seconds]
<FLHerne>
next up, can you run Android apps in your Win11 translation layer in WINE?
<FLHerne>
I bet you can compile WINE for Android and make it loop
<HdkR>
Integrating Android applications is definitely one way to bolster the number of "native" ARM apps running on Windows ARM :D
gouchi has quit [Remote host closed the connection]
pendingchaos has joined #dri-devel
<robclark>
alyssa: looks like .trace file was truncated
<robclark>
so nfs issue or something like that
<robclark>
I saw that happen once before
<mareko>
gawin: if you want to disable alpha, that would be colormasking, which destroys perf
<alyssa>
robclark: so reassign to marge?
<robclark>
yeah
<robclark>
and hope that whatever network issue happened has resolved itself, I guess
<alyssa>
Woof. alright
<gawin>
mareko: so probably this is not it, do you perhaps know tools like renderdoc but which is working with gl 2.x?
<robclark>
alyssa: tbf, it is an infra flake I've only seen one, and that was maybe a month or two ago.. but would be nice if the trace runner thing detected this case better
<mareko>
gawin: apitrace?
dongwonk has quit [Remote host closed the connection]
dongwonk has joined #dri-devel
<alyssa>
robclark: sure
<alyssa>
I don't merge enough code these days to have CI related meltdowns.
<mareko>
Venemo: nir_schedule doesn't work with SSA :(
<alyssa>
mareko: that could presumably be fixed
<alyssa>
Though I guess backends that are willing to ingest SSA themselves are also doing their own scheduling.
<robclark>
mareko: fwiw, trying to schedule things around texture fetches (and other instructions whose consumers would stall) is a thing we handle in driver backend instruction scheduler in ir3
<robclark>
(albeit sometimes with better results than others.. there are some pedantic cases where register pressure can increase)
<mareko>
increasing register pressure is kinda the point
<Venemo>
mareko :(
<robclark>
yeah..to a point.. I'd kinda like to make scheduler aware of register pressure so it can make the tradeoff about register pressure vs stalling better
<alyssa>
a Hard problem
<Venemo>
mareko: ACO on RadeonSI?
<pendingchaos>
I think nir_schedule probably could easily
<pendingchaos>
I don't know why it doesn't
<pendingchaos>
(work with ssa)
<alyssa>
pendingchaos: because it's only used by a single driver AFAIK and that driver uses it after lowering SSA
<Venemo>
pendingchaos: if it doesn't handle SSA, how did you try it?
<pendingchaos>
from-ssa -> schedule -> to-ssa
<alyssa>
awful :-P
<Venemo>
oh, okay
<pendingchaos>
just need to make phis unmovable, I think
<mareko>
block-level scheduling would be sufficient
<mareko>
no phis
<anholt>
ok, back and could maybe talk nir_schedule.
<anholt>
alyssa: we've seen intermittent fails where traces are truncated. I checked and we have lots of free space. so my guess is that the replay's internal downloading stuff just lost its connection and needed to retry, or something
<anholt>
but it doesn't generate logs that I've seen
<anholt>
unfortunately, the trace replay stuff got moved to piglit, so it's hard to work on now so I haven't been motivated to see what we can do about it.
vivijim has quit [Ping timeout: 480 seconds]
<anholt>
mareko: I agree that we can probably make nir_schedule work with SSA easily. my concern with the pass as I left it is that it's easy for it to make things worse. what I wanted to do to it next was the paper "A randomized heuristic approach to register allocation"
<pendingchaos>
if it's used to group texture instructions and otherwise preserve the order of instructions, maybe it won't be too bad?
<anholt>
pendingchaos: the other piece that's an issue is that different drivers would probably want different scheduling heuristics, like "just group texture instructions (but not too many)?")
<anholt>
so there's some shared work of making the dag and making a schedule to consider using a heuristic, but then some driver specific work of what the heuristic is and how to evaluate the proposed schedule
Duke`` has quit [Ping timeout: 480 seconds]
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
camus has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
camus1 has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
adjtm is now known as Guest4136
adjtm has joined #dri-devel
<alyssa>
right now the bifrost GLES stack is too memory bound for me to pay much attention to compiler stuff :(
<alyssa>
otoh maybe if I weren't bailing on instruction scheduling the memory latencies could be better hidden.
Guest4136 has quit [Ping timeout: 480 seconds]
<jekstrand>
boo memory
<alyssa>
jekstrand: what?
<alyssa>
did I say something?
<alyssa>
...I can't quite remember 🙃
<jekstrand>
Got paged out?
<alyssa>
mm... paging...
danvet has quit [Ping timeout: 480 seconds]
gawin has quit [Remote host closed the connection]
<karolherbst>
I need to figure out if I can access that info from the API
<alyssa>
here, spam bot authors take note ^^ :-p
<karolherbst>
alyssa: I mean.. you might not knowm but in the past people were convinced that writing name at provider dot com is a good way of preventing spambots to find your email and I am currently wondering if there was a discussion on the git mailing list about this as well at some point in time :D
pcercuei has quit [Quit: dodo]
boistordu has quit [Remote host closed the connection]