05:27 | Bertl | off to bed now ... have a good one everyone!
| |
05:28 | Bertl | changed nick to: Bertl_zZ
| |
05:32 | BAndiT1983|away | changed nick to: BAndiT1983
| |
12:58 | RexOrCine | left the channel | |
13:12 | Bertl_zZ | changed nick to: Bertl
| |
13:12 | Bertl | morning folks!
| |
13:14 | BAndiT1983 | changed nick to: BAndiT1983|away
| |
13:33 | RexOrCine | joined the channel | |
13:54 | RexOrCine | left the channel | |
14:11 | RexOrCine | joined the channel | |
14:31 | RexOrCine | left the channel | |
14:38 | RexOrCine | joined the channel | |
14:47 | RexOrCine | left the channel | |
15:04 | danieel | left the channel | |
15:05 | danieel | joined the channel | |
15:05 | RexOrCine | joined the channel | |
15:13 | RexOrCine | left the channel | |
15:26 | RexOrCine | joined the channel | |
15:43 | vnksnkr | joined the channel | |
16:00 | Bertl | meeting time!
| 16:00 | vup | is here
|
16:00 | Bertl | se6ast1an is busy today with a shooting (let's hope he will not get arrested ;)
| |
16:00 | Bertl | and he asked me to moderate the meeting for today, so please /msg me instead
| |
16:02 | Bertl | seems that it will be a very short meeting today ...
| |
16:02 | Bertl | vup: do you want to report anything?
| |
16:03 | vup | I have a small bit to report
| |
16:03 | Bertl | then please go right ahead ...
| |
16: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 :)
| |
16: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
| |
16:05 | vup | furthermore I want to switch away from fuse to a (semi custom) self documenting tcp rpc protocol
| |
16:05 | Bertl | interesting ... care to elaborate?
| |
16: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
| |
16:06 | vup | Bertl: sure
| |
16:06 | vup | I guess the main points are:
| |
16:06 | vup | 1. Transport over tcp
| |
16: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
| |
16: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
| |
16:10 | vup | 3. Serialization uses something called serde bincode, which already has implementations in all the languages mentioned above
| |
16:10 | vup | I think thats the main points of the RPC thingy
| |
16:10 | Bertl | nice
| |
16:11 | Bertl | well, looking forward to that ...
| |
16:11 | Bertl | anything else you would like to report?
| |
16: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
| |
16:11 | vup | Which brings me to the final point:
| |
16: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
| |
16:12 | vup | There is a rough (rust centric) sketch of all of this here: https://codimd.niemo.de/Jv9uOS8pTeufU0_MwUsDjA?both
| |
16:13 | vup | (please don't mess with the document too much :)
| |
16: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
| |
16:13 | Bertl | excellent idea!
| 16:13 | bluez | is late..
|
16:14 | Bertl | bluez: you want to go next?
| |
16:14 | bluez | sure!
| |
16:14 | Bertl | then please do so ;)
| 16:14 | anuejn | is late but here
|
16: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)
| |
16:16 | bluez | this way we can make sure that our (re)configuration frames do not also modify any dynamic resources
| |
16:16 | bluez | https://forums.xilinx.com/t5/Implementation/Map-logic-only-to-SLICEL-and-not-SLICEM-in-7-Series-FPGA/td-p/1234083#M30348
| |
16:17 | bluez | posted on the fourm and got the solution for that... we have to use plbocks here.. so I'll use that soon
| |
16: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
| |
16:18 | bluez | https://github.com/Swaraj1998/reg-test
| |
16:18 | bluez | code can be found here ^
| |
16:19 | bluez | The build script also now writes out the register to slice mappings to a file
| |
16:20 | Bertl | excellent!
| |
16: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
| |
16:20 | bluez | so that we can identify which frames modify which register instance... for this I have used a custom attribute called REG_NAME...
| |
16: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
| |
16:22 | vup | bluez: sure feel free to send it to me when you get the chance
| |
16:23 | bluez | okay, I'll dm you in a while
| 16:23 | Bertl | wouldn't mind to receive a copy either ;)
|
16:23 | bluez | yes sure! ':D
| |
16:23 | bluez | i forgot to send it to you.. there wasn't much time and it was for official univ purposes anyway...
| |
16:24 | Bertl | yeah, no problem
| |
16:24 | bluez | so that's it from me!
| |
16:24 | Bertl | great work! thanks!
| |
16:24 | Bertl | anuejn: anything you want to report?
| |
16:25 | anuejn | yup
| |
16:25 | Bertl | then please go ahead
| |
16:25 | anuejn | I did some more work on the ui framework for the axiom recorder
| |
16:26 | anuejn | I can now handle input and render text and sliders :) (https://files.niemo.de/Peek%202021-04-20%2023-50.mp4)
| |
16:26 | anuejn | Currently I am in progress of improving performance / lowering cpu usage by caching layout & tesselation results
| |
16: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)
| |
16:28 | anuejn | thats it from my side
| |
16:28 | Bertl | great! thanks!
| |
16:29 | Bertl | anybody else who wants to report something?
| |
16: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
| |
16:31 | Bertl | but I found some more time to play with the magewell hdmi capture card, which is really a beautifull design
| |
16:31 | Bertl | http://vserver.13thfloor.at/Stuff/MAGEWELL/magewell.jpg
| |
16:32 | vup | Love to see the ECP5 :)
| |
16: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
| |
16:32 | Bertl | I tried to configure a number of custom modes and even succeeded to get a full sensor compatible format
| |
16:33 | Bertl | (2048x1536 pixel) of course at a lower than desired frame rate
| |
16: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'
| |
16:34 | vup | nice
| |
16:34 | Bertl | i.e. something which works without writing new gateware or firmware for a cypress/FPGA solution
| |
16:35 | Bertl | of course, ultimately we want to drop the HDMI intermediate and replace it with a direct USB solution
| |
16:35 | Bertl | that's it from my side for this week
| |
16:35 | vup | Sounds great
| |
16:35 | Bertl | unless somebody has a last-minute information/report/question, this would conclude the meeting for today
| |
16:36 | Bertl | thanks everybody for your time and till next week ;)
| |
16:38 | Bertl | meeting concluded
| |
17:39 | Bertl | off for now ... bbl
| |
17:39 | Bertl | changed nick to: Bertl_oO
| |
18:34 | vnksnkr | left the channel | |
19:24 | RexOrCine | left the channel | |
20:25 | anuejn | Bertl: If you have decided on a transfer format I can implement decoding in the recorder software
| |
20:26 | anuejn | how is the capture card exposed on the linux side? v4l2?
| |
20:28 | Bertl_oO | yes, it works as uvc device and is well supported by v4l2
| |
22:18 | danieel | left the channel | |
22:25 | danieel | joined the channel | |
22:46 | aombk | left the channel | |
22:49 | aombk | joined the channel |