Current Server Time: 14:41 (Central Europe)

#apertus IRC Channel Logs

2021/04/26

Timezone: UTC


06:27
Bertl
off to bed now ... have a good one everyone!
06:28
Bertl
changed nick to: Bertl_zZ
06:32
BAndiT1983|away
changed nick to: BAndiT1983
13:58
RexOrCine
left the channel
14:12
Bertl_zZ
changed nick to: Bertl
14:12
Bertl
morning folks!
14:14
BAndiT1983
changed nick to: BAndiT1983|away
14:33
RexOrCine
joined the channel
14:54
RexOrCine
left the channel
15:11
RexOrCine
joined the channel
15:31
RexOrCine
left the channel
15:38
RexOrCine
joined the channel
15:47
RexOrCine
left the channel
16:04
danieel
left the channel
16:05
danieel
joined the channel
16:05
RexOrCine
joined the channel
16:13
RexOrCine
left the channel
16:26
RexOrCine
joined the channel
16:43
vnksnkr
joined the channel
17:00
Bertl
meeting time!
17:00
vup
is here
17:00
Bertl
se6ast1an is busy today with a shooting (let's hope he will not get arrested ;)
17:00
Bertl
and he asked me to moderate the meeting for today, so please /msg me instead
17:02
Bertl
seems that it will be a very short meeting today ...
17:02
Bertl
vup: do you want to report anything?
17:03
vup
I have a small bit to report
17:03
Bertl
then please go right ahead ...
17:03
vup
I have started thinking about the (hopefully final :) redesign of the control daemon, which incorporates all the lessons learned from the last two (three) versions :)
17:04
vup
The general idea is to have much stricter types and work more with the rust type system, to avoid the confusing mess some parts of the current control daemon is
17:05
vup
furthermore I want to switch away from fuse to a (semi custom) self documenting tcp rpc protocol
17:05
Bertl
interesting ... care to elaborate?
17:06
vup
The way I currently envision implementing that should easily allow atleast rust, c++, go, python, typescript, java and c# clients, which covers most bases
17:06
vup
Bertl: sure
17:06
vup
I guess the main points are:
17:06
vup
1. Transport over tcp
17:08
vup
2. Each rpc function / object providing rpc functions is self documenting, meaning it generates (at runtime) a list of available functions and their argument types / return value. The Argument types / return types are serialized into a generic description, which allows clients to dynamically generate serializers and deserializers for the argument values / return values
17:09
vup
This dynamic generation of the serializer / deserializer will probably only be done in the more dynamic languages like python, while rust / c++ / go and the like will probably use a description of the rpc functions generated in a preprocessing step
17:10
vup
3. Serialization uses something called serde bincode, which already has implementations in all the languages mentioned above
17:10
vup
I think thats the main points of the RPC thingy
17:10
Bertl
nice
17:11
Bertl
well, looking forward to that ...
17:11
Bertl
anything else you would like to report?
17:11
vup
Especially the dynamic generation part will hopefully nicely integrate into some existing workflows which for example anuejn is using, where he generates a python driver code piece together with a bitstream / with the gateware
17:11
vup
Which brings me to the final point:
17:12
vup
We already played a bit with embedding a more dynamic "scripting" language into the control daemon and (I think atleast) all liked it, so going further than lua the plan is currently to allow embedding python
17:12
vup
There is a rough (rust centric) sketch of all of this here: https://codimd.niemo.de/Jv9uOS8pTeufU0_MwUsDjA?both
17:13
vup
(please don't mess with the document too much :)
17:13
vup
I think thats it, if anybody has some feedback or ideas for the control daemon, feel free to message me, I am looking forward to discuss
17:13
Bertl
excellent idea!
17:13
bluez
is late..
17:14
Bertl
bluez: you want to go next?
17:14
bluez
sure!
17:14
Bertl
then please do so ;)
17:14
anuejn
is late but here
17:15
bluez
so last week i was trying to put some constraints so that our logic only ends up in SLICEL and not in SLICEM(which contains dynamic component)
17:16
bluez
this way we can make sure that our (re)configuration frames do not also modify any dynamic resources
17:16
bluez
https://forums.xilinx.com/t5/Implementation/Map-logic-only-to-SLICEL-and-not-SLICEM-in-7-Series-FPGA/td-p/1234083#M30348
17:17
bluez
posted on the fourm and got the solution for that... we have to use plbocks here.. so I'll use that soon
17:18
bluez
other than this... i tried to generalize the structure of the design... so that we can create any type of register (boolean, constant etc.) of any width
17:18
bluez
https://github.com/Swaraj1998/reg-test
17:18
bluez
code can be found here ^
17:19
bluez
The build script also now writes out the register to slice mappings to a file
17:20
Bertl
excellent!
17:20
vup
bluez: nice, is there / are you planning to write some documenation about how this all works together in the end? I think anuejn and me would be very interested to port this to the nmigen gateware someday
17:20
bluez
so that we can identify which frames modify which register instance... for this I have used a custom attribute called REG_NAME...
17:21
bluez
vup: sure! I already have a midterm report that i sent to my univ.. I can send you that for now... but yea I will document it later as well I think
17:22
vup
bluez: sure feel free to send it to me when you get the chance
17:23
bluez
okay, I'll dm you in a while
17:23
Bertl
wouldn't mind to receive a copy either ;)
17:23
bluez
yes sure! ':D
17:23
bluez
i forgot to send it to you.. there wasn't much time and it was for official univ purposes anyway...
17:24
Bertl
yeah, no problem
17:24
bluez
so that's it from me!
17:24
Bertl
great work! thanks!
17:24
Bertl
anuejn: anything you want to report?
17:25
anuejn
yup
17:25
Bertl
then please go ahead
17:25
anuejn
I did some more work on the ui framework for the axiom recorder
17:26
anuejn
I can now handle input and render text and sliders :) (https://files.niemo.de/Peek%202021-04-20%2023-50.mp4)
17:26
anuejn
Currently I am in progress of improving performance / lowering cpu usage by caching layout & tesselation results
17:27
anuejn
Also I am thinking about other ways to improve performance and add how to add custom shaders for ui elements and clipping (needed for example for scroll containers)
17:28
anuejn
thats it from my side
17:28
Bertl
great! thanks!
17:29
Bertl
anybody else who wants to report something?
17:30
Bertl
from my side, there is not too much to report this week, I've been mostly busy with unrelated stuff as well as reviewing the GSoC student proposals
17:31
Bertl
but I found some more time to play with the magewell hdmi capture card, which is really a beautifull design
17:31
Bertl
http://vserver.13thfloor.at/Stuff/MAGEWELL/magewell.jpg
17:32
vup
Love to see the ECP5 :)
17:32
Bertl
besdies seeing a number of good old friends on the PCB there it is really nice to work with and it seems to do exactly what we want
17:32
Bertl
I tried to configure a number of custom modes and even succeeded to get a full sensor compatible format
17:33
Bertl
(2048x1536 pixel) of course at a lower than desired frame rate
17:33
Bertl
that said, I have a bunch of ideas to make generic data transfer via HDMI work there which might allow for an intermediate solution for the 'data transfer problem'
17:34
vup
nice
17:34
Bertl
i.e. something which works without writing new gateware or firmware for a cypress/FPGA solution
17:35
Bertl
of course, ultimately we want to drop the HDMI intermediate and replace it with a direct USB solution
17:35
Bertl
that's it from my side for this week
17:35
vup
Sounds great
17:35
Bertl
unless somebody has a last-minute information/report/question, this would conclude the meeting for today
17:36
Bertl
thanks everybody for your time and till next week ;)
17:38
Bertl
meeting concluded
18:39
Bertl
off for now ... bbl
18:39
Bertl
changed nick to: Bertl_oO
19:34
vnksnkr
left the channel
20:24
RexOrCine
left the channel
21:25
anuejn
Bertl: If you have decided on a transfer format I can implement decoding in the recorder software
21:26
anuejn
how is the capture card exposed on the linux side? v4l2?
21:28
Bertl_oO
yes, it works as uvc device and is well supported by v4l2
23:18
danieel
left the channel
23:25
danieel
joined the channel
23:46
aombk
left the channel
23:49
aombk
joined the channel