anarsoul|2 has quit [Read error: No route to host]
anarsoul has joined #dri-devel
gnuiyl has quit [Remote host closed the connection]
amarsh04 has quit []
u-amarsh04 has joined #dri-devel
gnuiyl has joined #dri-devel
Mangix has joined #dri-devel
<DemiMarie>
FL4SHK: is your goal "have fun", "create something that is used by millions", or something in between?
yuq825_ has quit []
yuq825 has joined #dri-devel
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul has joined #dri-devel
<FL4SHK[m]>
Demi: for which of my projects?
<FL4SHK[m]>
"have fun" is the number one goal
<FL4SHK[m]>
for all my personal projects, but I also want more than me to be interested in my projects
<DemiMarie>
Do you want your ISA to be better than all the others?
<FL4SHK[m]>
... frankly it's okay if that's not the case
<FL4SHK[m]>
I'm happy to do something that is "good for an FPGA implementation"
<FL4SHK[m]>
btw, my CPU's implementation is generated by a CPU generator thing I wrote
<DemiMarie>
Oooh interesting!!!
<FL4SHK[m]>
I feed the CPU generator an instruction decoder and a list of kinds of instructions
<FL4SHK[m]>
then it spits out the core of a CPU
<FL4SHK[m]>
it's best used with RISC type CPUs
<DemiMarie>
Do you want to go out of order or stick with in-order?
The_Company has joined #dri-devel
<FL4SHK[m]>
so far, I've only stuck with in-order, but generating an out of order CPU would be cool some time too
<FL4SHK[m]>
the generator only supports integer operations directly right now
<FL4SHK[m]>
but it's able to do something like a classically microcoded CPU
<FL4SHK[m]>
if you want something not directly supported by the generator
<DemiMarie>
Now I'm imagining an HTTP server implemented in the FPGA as an offload device.
<FL4SHK[m]>
haha
<FL4SHK[m]>
you could do something like that
<DemiMarie>
The idea being the fastest web server ever.
<FL4SHK[m]>
haha
<DemiMarie>
Because it is all-hardware in the fast path.
<FL4SHK[m]>
the generator is all open source
<DemiMarie>
Nice
<FL4SHK[m]>
called libsnowshouse on my github
<DemiMarie>
Could be useful for custom DSPs
<DemiMarie>
Where there is a domain-specific operation one wants to go really fast.
<FL4SHK[m]>
honestly, yeah, that's a good point
<FL4SHK[m]>
I made it so the FPGA code can actually be a pretty small *and* fast CPU, regarding both LUT count and clock frequency
<FL4SHK[m]>
that took a few weeks ago
Company has quit [Ping timeout: 480 seconds]
<FL4SHK[m]>
that took a few weeks of effort*
<FL4SHK[m]>
the sample CPU I made with the generator reaches 130 MHz in my Arty A7 100T
<FL4SHK[m]>
for that CPU, I actually wrote a GCC port and GNU Binutils port
<FL4SHK[m]>
but it doesn't have virtual memory support
<FL4SHK[m]>
... that will come eventually
<FL4SHK[m]>
along with support for actual cache coherence
nerdopolis has joined #dri-devel
<DemiMarie>
FL4SHK: What about using the FPGA as a JIT target?
<DemiMarie>
Also, will it have a GPU? What about using the FPGA LUTs themselves as the compilation target?
NiGaR has quit [Ping timeout: 480 seconds]
NiGaR has joined #dri-devel
<FL4SHK[m]>
Demi: JIT as in JIT compile FPGA code? or JIT compile to machine code for a CPU running on the FPGA?
riteo has joined #dri-devel
<FL4SHK[m]>
the former is virtually impossible
<DemiMarie>
FL4SHK: The first one of course, the second is too mundane.
<FL4SHK[m]>
it's virtually impossible in any practical way
<FL4SHK[m]>
takes *way way* too long to compiles for FPGAs
<FL4SHK[m]>
Full fledged compiling for FPGAs is an NP hard problem, and it takes my decently beefy laptop a long time to compile the code and the way down to bitstream
<Venemo>
zmike, karolherbst, alyssa, gfxstrand, for splitting off NIR passes from nir.h, what do you think would be the best way? 1 header file per pass (there are already some examples of this), or one header for all passes? or something in between?
<FL4SHK[m]>
the GPU I'm developing for my custom game system is going to be fixed function, but the CPU for my custom game system will have vector instructions at least
benjaminl has quit [Read error: Connection reset by peer]
<FL4SHK[m]>
I'm implementing the GPU in PipelineC.
benjaminl has joined #dri-devel
<FL4SHK[m]>
It's been based on my software rasterizer
<FL4SHK[m]>
which was written in C++. Additionally, quite a bit of the code isn't that hard to translate over to PipelineC.
heat has quit [Ping timeout: 480 seconds]
alane has quit []
Peuc has quit [Quit: Peuc]
alane has joined #dri-devel
<DemiMarie>
FL4SHK: I mean something that is *much* less optimized, but still faster than interpreting the code, if possible.
<FL4SHK[m]>
maybe something with partial reconfiguration?
<DemiMarie>
I was thinking of a greedy algorithm for placement that stops when it runs out of space, and yes.
<DemiMarie>
The idea is that the FPGA modifies its own configuration at runtime.
<FL4SHK[m]>
Plus the FPGA synthesis plus pnr software isn't open source
<DemiMarie>
You would need an FPGA for which the software is open source
<FL4SHK[m]>
yeah
davispuh has quit [Ping timeout: 480 seconds]
<FL4SHK[m]>
or reverse engineered or something
<DemiMarie>
Anyway this is getting off-topic, sorry Venemo.
<FL4SHK[m]>
ah sorry
<DemiMarie>
A Mesa backend for an FPGA, or a DRM driver for an FPGA, would be on-topic though.
nerdopolis has quit [Ping timeout: 480 seconds]
surajkandpal has joined #dri-devel
nerdopolis has joined #dri-devel
surajkandpal has left #dri-devel [#dri-devel]
KitsuWhooa has quit [Quit: Unable to handle kernel NULL pointer dereference at null]
nerdopolis has quit [Ping timeout: 480 seconds]
KitsuWhooa has joined #dri-devel
<airlied>
cmarcelo: just fyi when I played with it a long while ago I think the sycl llama.cpp backend was 4x faster than the mesa vulkan one
<airlied>
from memory I think mesa was 0.5 my CPU and sycl was 2x my cpu roughly, I think it was on an IGP, but I also had an A770 so memory is a bit fuzzy
<cmarcelo>
airlied: tks. we might have issues on our side but I think also some tweaking can be done on the shader. I'll try the SYCL tomorrow to see the kind of partitioning they are doing for each thread. my suspicion is in vulkan we are trying to handle too much data and getting overwhelmed by spilling.
<tnt>
karolherbst: Actually my bad, it also doesn't work with rusticl. I just didn't notice at first because in my case it causes a segfault (it's a bug, if it finds GL but not GLX/EGL). For rusticl, it just ends up without cl/gl sharing and I hadn't noticed at first.
<tnt>
But using LD_DEBUG=all I can see the lookups done by rusticl also fail to find either glXGetProcAddress or eglGetProcAddress
fab has quit [Quit: fab]
mivanchev has quit [Quit: Leaving]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
mivanchev has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
<mivanchev>
hey, does anyone know where the megadriver is being dlopen'd on X11 when using OpenGL?
<mivanchev>
in the gbm backend?
eukara has quit []
sima has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
paulk-bis has joined #dri-devel
anarsoul has joined #dri-devel
<MrCooper>
mivanchev: no GBM should be involved in that scenario
<mivanchev>
MrCooper, well can you help me locate the place starting from dri3_create_screen
<mivanchev>
I see the entry points in dril_dri and maybe that's the mega driver but i can't find where it's getting dlopen'd
<MrCooper>
I'd have to dig myself, sorry
<MrCooper>
dril is only used in Xorg
<MrCooper>
client side goes directly to libgallium
<mivanchev>
yes I figured that much too! thank you!!!
<MrCooper>
so are you asking about in Xorg?
<mivanchev>
yes, it's Xorg
<mivanchev>
i got confused because i found a dlopen in GBM
vliaskov has joined #dri-devel
<mivanchev>
that supposedly loads drivers
<MrCooper>
I mean, are you asking about the server side or client side?
<mivanchev>
which is const __DRIextension **__driDriverGetExtensions_##drivername(void);
<MrCooper>
it doesn't, dril is only used on the server side
<mivanchev>
can you explain to me shortly what "server-side" means in mesa?
frankbinns has joined #dri-devel
<MrCooper>
inside the Xorg process
<MrCooper>
dril is just a backwards compatibility layer for the Xorg process, it's not used anywhere else
<mivanchev>
OK, thought so
<mivanchev>
so the question remains where the megadriver is loaded :/
<MrCooper>
the "megadriver" is libgallium now
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
PerfecT78895 has joined #dri-devel
PerfecT78895 has left #dri-devel [#dri-devel]
rasterman has quit [Quit: Gettin' stinky!]
<mivanchev>
MrCooper, I guess I'm trying to find out, somewhere around 'driCreateNewScreen3' where the driver name is used to get the initialization methods
paulk-bis has joined #dri-devel
phasta has joined #dri-devel
apinheiro has joined #dri-devel
<MrCooper>
zamundaaa[m]: I thought I saw somebody somewhere mention that KWin uses drmModeMoveCursor / DRM_IOCTL_MODE_CURSOR(2) for moving the cursor even when otherwise using atomic KMS; I can't seem to find such code on the current master branch though?
jkrzyszt has joined #dri-devel
<emersion>
i don't think it does?
<MrCooper>
do you know of any other compositor which does?
u-amarsh04 has quit []
<zamundaaa[m]>
MrCooper: it did a very long time ago
<MrCooper>
why did it stop?
amarsh04 has joined #dri-devel
<zamundaaa[m]>
The cursor move invalidates previous atomic test results. In practice that caused atomic commits to fail with hardware rotation on AMD for example
mehdi-djait3397165695212282475 has joined #dri-devel
rasterman has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
<MrCooper>
I see
<MrCooper>
did it seem to work fine in general with the nvidia driver though?
<emersion>
yeah, mixing legacy and atomic is not a good idea
<MrCooper>
that's my only real worry for mutter at this point, it doesn't use test commits much yet (and when that changes, doesn't seem hard to suspend asynchronous cursor moves between test commits and the real one)
<emersion>
chromeos used to do it as well, and in some cases the cursor just stopped being displayed or got stuck
<MrCooper>
I mean, it's essentially the same as what happens with Xorg
<emersion>
xorg doesn't use atomic so
<MrCooper>
I'm aware
<MrCooper>
still fundamentally the same interaction between flips and cursor moves
<emersion>
if you only set state which was settable with legacy api, maybe
<emersion>
if you set some other state, then no
<emersion>
the real fix here is to improve the atomic api
<MrCooper>
no time for that for mutter 48
The_Company has quit []
guludo has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
rcf has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
rcf has joined #dri-devel
<bbrezillon>
sima: just a quick feedback regarding yesterday's discussion around syncobj waits. Turns out I was doing one iteration before being blocked, so I'm not sure the race exists
<sima>
bbrezillon, hm
<sima>
bbrezillon, I guess mildly refactoring that code, pulling out helpers and reducing those monster stacked if ladders would still be good
<sima>
because I can't parse that thing anymore :-/
<sima>
s/if ladders/if conditions/
<bbrezillon>
agreed
nerdopolis has joined #dri-devel
chewitt has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
valpackett has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
haaninjo has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
paulk-ter has joined #dri-devel
paulk-bis has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
balrog_ has quit []
balrog has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mehdi-djait3397165695212282475 has quit []
mivanchev has quit [Quit: Leaving]
bolson has joined #dri-devel
kzd has joined #dri-devel
robmur01 has quit [Remote host closed the connection]