**** BEGIN LOGGING AT Mon Mar 29 02:59:56 2021 Mar 29 05:01:28 Hello Mar 29 05:01:49 I am new here and don't where to start Mar 29 05:02:30 Can anyone help me how can I work on any idea? Mar 29 05:04:37 Jagannadha Varma Mandhapati: There is a pre application requirement and a list of ideas here: https://elinux.org/BeagleBoard/GSoC/Ideas-2021#Ideas Mar 29 06:12:39 lorforlinux Here is a first draft Mar 29 06:12:39 https://elinux.org/BeagleBoard/GSoC/2021_Proposal/usb_configfs_in_device_tree Mar 29 06:12:39 Please let me know what you think of this. **** BEGIN LOGGING AT Mon Mar 29 06:29:37 2021 Mar 29 07:23:25 * satacker[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/gKlJtBnwwOfudIWVDkIkqybA/message.txt > Mar 29 07:23:51 * satacker[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/TxPzhjQEXTZgAbrQKDmAJqIS/message.txt > Mar 29 07:25:12 * satacker[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/SDXztrSqOvqVWQHINCVsibrk/message.txt > Mar 29 07:28:47 * satacker[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/ZCnIqvSqAaaRvgAQgqtdxFUp/message.txt > Mar 29 07:29:10 You mean something of a generator? This is a common idea with different frameworks I am familiar with, like nrf or even Intel quartus for generating device tree entries for devices Mar 29 07:29:35 Not sure if this is that quick to code up Mar 29 07:30:09 I think he means something more on the lines of raspic-config Mar 29 07:30:22 and not kconfig Mar 29 07:32:42 Yes, but jduchniewicz 's idea about adding real time overlaying to device trees using beagle-config is nice too. vedant16 has pointed out correctly . I think device-trees would be the last thing for this due to time - constraints Mar 29 07:33:00 sounds good Mar 29 07:41:42 still good to be having some entry-level configuration tools -> kconfigs are a time-saver Mar 29 07:42:15 so I strongly believe adding anything making the development time faster would be a good idea Mar 29 07:46:39 Jagannadha Varma Mandhapati: Hi, have a look at the Ideas list and discuss the projects you are interested in with the mentors thoroughly on this channel so that you can start working on a proposal. Make sure to follow the prerequisites on the ideas page. Mar 29 07:46:52 Here's the proposal template: https://elinux.org/BeagleBoard/GSoC/2021ProposalTemplate Mar 29 07:48:59 If you are a mentor (as i cannot see ur name in the mentors list), are you willing to mentor me on this idea ? Mar 29 07:49:30 he's not a mentor Mar 29 07:49:44 thought so Mar 29 07:50:01 pratimu: what is ur opinion ? Mar 29 07:50:52 on what? Mar 29 07:51:00 Reading the logs Mar 29 07:52:01 no, I am not a mentor šŸ˜‡ Mar 29 07:52:59 * satacker[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/HMMbBnNqCHFALEmWTfyuCUHi/message.txt > Mar 29 07:53:13 * satacker[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/yCiFYvmpsxgJeQXuNuYNfEzg/message.txt > Mar 29 07:53:52 jduchniewicz: Whatā€™s your proposal/idea? Mar 29 07:54:05 Have you posted on the GSoC forum? Mar 29 07:55:52 * satacker[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/pJpjmXmbTDqTMcjOPiyLmfdL/message.txt > Mar 29 07:56:25 * vedant16[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/qWVqlRrHoBKWaloFZxgdGTAU/message.txt > Mar 29 07:57:08 he has worked on device trees, he might help you out with proposal ig. Mar 29 07:57:17 satacker: You have a good idea at hand, work on ā€œscoping itā€ Mar 29 07:57:24 Hi Abhishek Mar 29 07:58:14 Hi vedant16! Mar 29 07:58:43 Happy Holi to folks who observe the festival of colors! Mar 29 07:59:07 Happy Holi to everyone :) Mar 29 07:59:45 Happy Holi! Mar 29 07:59:57 satacker: configFS is beyond my expertise, maybe other folks can help. But automated edits to config files sounds like a good idea Mar 29 07:59:57 Happy Holi ! Mar 29 08:00:11 Happy Holi everyone! Mar 29 08:00:22 * Abhishek[m]_ looks at configfs Mar 29 08:01:36 > * <@abhishek_:matrix.org> looks at configfs Mar 29 08:01:36 That's great. Mar 29 08:02:13 (I thought you meant you are available for this as a mentor) Mar 29 08:03:12 I might be primary on one or two projects, but nothing prevents me from looking at other areas that may be interesting Mar 29 08:04:13 Also about your idea of cloud-ci on beagle , i looked up for nfs, tftp. Apart from configuring beagle image to mount on nfs and using tftp for u-boot, all the cloud part was off my limits Mar 29 08:04:39 Why off limits? Mar 29 08:05:14 I don't know how I would configure an instance of VM Mar 29 08:05:31 Go on Mar 29 08:06:38 I could think of a script that is generic for any linux distro using kernel-nfs tools Mar 29 08:06:55 You mean cloud VM? Mar 29 08:07:03 yes Mar 29 08:08:16 Script (i)refers to? (ii) Where does it run (Beagle, host PC, ...)? Mar 29 08:09:39 on host pc, but it is still unclear to me about how beagle will be assigned IP even for u-boot to transmit through tftp when it is not on local network Mar 29 08:11:40 * Reference https://elinux.org/TFTP_Boot_and_NFS_Root_Filesystems Mar 29 08:11:40 Script that does mount kernel on nfs Mar 29 08:11:40 on host pc, but it is still unclear to me about how beagle will be assigned IP even for u-boot to transmit through tftp when it is not on local network Mar 29 08:14:28 Correction - We will have to configure u-boot to use tftp Mar 29 08:15:04 And I think there might be security concerns using plain tftp Mar 29 08:15:34 Yes, there is Mar 29 08:19:36 Should I rush for the above beagle-config idea to make a proper proposal Abhishek ? Mar 29 08:21:02 First boot experience is a bit strange, but TFTP is something thatā€™s baked into the AM335x chips ROM and you canā€™t do anything about it unless you make a more securely booting chip Mar 29 08:21:26 Also, there are multiple types of boot security Mar 29 08:24:07 Whatā€™s the proposal timeline for students again, 29th March-? Mar 29 08:24:30 13 april Mar 29 08:24:37 Hmm, 2weekd Mar 29 08:28:12 satacker: Go ahead Mar 29 08:31:23 Thank you. Will make a complete proposal according to the template provided. Will try to make it in a day from now. Mar 29 08:31:53 * Thank you. Will make a complete proposal according to the template provided. Will try to make it in a day from starting right now. Mar 29 09:37:35 satacker: I am working on [this](https://elinux.org/BeagleBoard/GSoC/Ideas-2021#YOLO_models_on_the_X15.2FAI) proposal Mar 29 09:37:46 YOLO models on the X15/AI Mar 29 09:37:53 Okay Mar 29 09:38:30 Got in touch with ds2 and need to discuss tentative approaches (as there is a multitude of them) Mar 29 14:31:15 vedant16: For issue #5, (Links in the doc not working), using links to the documentation instead of links to internal pages (simppru.readthedocs.io/en/latest/install/install instead of /install/install) should solve the issue. Mar 29 14:31:15 This is also one of the recommendations in the official documentation here : https://docs.readthedocs.io/en/stable/automatic-redirects.html#redirecting-to-a-page Mar 29 14:31:15 I tried this and it works if I test using mkdocs serve. Should I send a pull request for this? Mar 29 14:32:45 Sure, please do Mar 29 14:33:01 I think this was added in newer version of mkdocs Mar 29 14:34:32 Could be Mar 29 14:35:20 I am just using a link to an outside website instead of a local resource Mar 29 14:51:16 sent a PR! Mar 29 15:24:40 cool, will merge tommorow Mar 29 15:25:04 wdym? Mar 29 15:26:55 I meant I replaced (/install/install) with (simppru.readthedocs.io/en/latest/install/install) Mar 29 16:17:44 I have pinged you on freenode stating all the current work i have done with respect to the project.It would be truly grateful if you could go through it once. Mar 29 16:18:00 > <@freenode_ds2:matrix.org> Yadnik Bendale: Yes, get yourself a native IRC client so we can talk...matrix is broken (20-30mins lag). Also waht's your timezone? Mar 29 16:18:01 * I have pinged you on freenode stating all the current work i have done with respect to the project. It would be truly grateful if you could go through it once. Mar 29 16:42:06 *yawn* Mar 29 16:49:18 jduchniewicz: Hello Mar 29 16:50:39 Hello Mar 29 16:51:05 ask away Mar 29 16:51:36 I have been digging around the proposed issue and come up with some questions Mar 29 16:51:58 It seems like we will be able to deploy YOLOv3 on newest TIDL Mar 29 16:52:18 https://e2e.ti.com/support/processors/f/processors-forum/964607/processor-sdk-dra8x-tda4x-tidl-model-import-error---yolov3/3567229?tisearch=e2e-sitesearch&keymatch=tidl%252520yolo#3567229 Mar 29 16:52:24 I wanted to ask as of how exactly can we use Darknet CNN Framework in the project OpenGLES acceleration for DL. Mar 29 16:52:58 Hi YadnikBendale[m].... we may lag due to the IRC-Matrix bridge, but ask away Mar 29 16:54:53 jduchniewicz1: do you know how much memory it'll take? I noticed the posts refects a different processor Mar 29 16:56:49 Yes sure.I understand the shaders part but can you please shed some light on how will the framework be used.Also can you suggest any resources or any previous repositories i can go through with respect to this project for furthur clarity? Mar 29 17:01:15 YadnikBendale[m]: It is somewhat of a new area for the Beagle stuff. On the Beagle, the processors have many hetrogenous cores. The goal of GLES GPGPU is to provide an offload (and maybe acceleration) for the main Cortex-A8.... being a new area - I think 2 aspects needs to be explored: timing - how bad/good is it and examples of how to do it (say, 2d conv, 1d conv, matrix mult, etc); resource are somewhat limited - most people Mar 29 17:04:54 True i searched a lot on this but could not get anything much of it. Mar 29 17:06:00 Yes i will look up in accordance to both the points you stated.Also only OPENGL ES 2.0 can be used right? Mar 29 17:06:09 YadnikBendale[m]: the same concepts of GPGPU on OpenGL applies with GLES - get a context, preferablly not on screen, render to it with shaders. the shaders do all the work Mar 29 17:06:29 YadnikBendale[m]: yes... there are some folks doing this as part of Android apps so there could be hints there Mar 29 17:07:19 YadnikBendale[m]: I have gotten the context creation working years ago but donno if the new drivers will allow it...but sorting out the mapping of the texture to data is something I haven't done Mar 29 17:09:07 I will search more on this and get back.Can we discuss more again tomorrow at the same time here? Mar 29 17:09:23 Weird, it seems like my messages from native client are blocked somehow when I have matrix on as well Mar 29 17:11:20 jduchniewicz1: odd... native client should completely independent... what client? Mar 29 17:11:35 So I will repeat my previous messages from here. It looks like for the previous versions of TIDL some operations like conv_2d were not supported but are now. However I do not know if they are supported by the EVE's on the AM5729 Mar 29 17:11:46 ds2: I am using irssi Mar 29 17:14:47 jduchniewicz1: I am somewhat concerned about memory... the YOLOv3 model is huge - with a GPU (as built with darket); it can want almost 6G of memory with CUDA Mar 29 17:15:36 Right, this is a valid consideration then. I will need to think about it then. Mar 29 17:15:40 jduchniewicz1: that is a valid concern; do you know if they are making this work by allowing for the ARM side to run things EVE/DSP can't run? Mar 29 17:16:31 I will need to look up the release of the library to confirm or deny that Mar 29 17:17:32 jduchniewicz1: the other thing that might be of interest is - from a time per image stand point, how much worse is YOLOv3 compared to YOLOv2 Mar 29 17:18:10 I doubt we'll get 30fps on the AI/x15 but can we get 1fps? 0.5fps? (on any version) Mar 29 17:18:47 YadnikBendale[m]: I can try... if you leave messages here, I'll get them eventually Mar 29 17:19:15 Hmm I recently had some experiments with Jetson Nano's and it achieved considerable FPS Mar 29 17:19:23 YadnikBendale[m]: I have a tighter window on Tue's but that often gets canceled Mar 29 17:19:36 jduchiewicz1: really? how fast? Mar 29 17:19:50 and are you running with darknet? Mar 29 17:19:54 ds2: I need to check my notes on that Mar 29 17:20:21 jduchniewicz1: I tried it on a Jetson a while back and it wasn't that fast... think it was till less then 1fps Mar 29 17:21:03 with the hacks to CUDA, I barely get 1fps on a RTX2060... the hacks were to get it to fit in the RAM on that Mar 29 17:21:40 It may be apples to oranges comparison though given the different architecture Mar 29 17:21:40 ds2: letme check Mar 29 17:21:41 Yes we can do that.I will put up the messages here then. Mar 29 17:24:32 jduchniewicz1: I don't expect it to get as fast and it also depends on the size of hte input image... I think I was using the darknet sample dog.jpg image as a test Mar 29 17:24:52 ds2: my memory was correct, around 10 fps for yolov3-tiny Mar 29 17:25:23 jduchiewicz1: another historical data point - I did try compiling the CL port of darknet blindly - that didn't work at all... out of memory Mar 29 17:25:40 but the images were quite small -> 220x220 Mar 29 17:25:44 jduchniewicz1: Oh... the -tiny version.... heh Mar 29 17:25:56 I am talking full YOLOv2/v3 Mar 29 17:26:03 tiny is considerably faster Mar 29 17:30:08 ds2: https://www.youtube.com/watch?v=-pVjXN9vwQE <- looks like can get some performance with little pruning Mar 29 17:32:02 ds2: I am not sure how big is the memory on the EVE's and this might heavily influence the results Mar 29 17:32:42 jduchniewicz1: yes Mar 29 17:33:07 jduchniewicz1: when do you plan to have a draft app? Mar 29 17:34:38 ds2: Since I don't have a BB AI I can do some code mockups and address all theoretical issues at the moment. I have something on my private elinux page here: https://elinux.org/User_talk:Jduchniewicz Mar 29 17:35:56 jduchniewicz1: that's understood... I am almost wondering if an x15 would be a better board to use for the. At least for development Mar 29 17:36:02 ds2: but it contains mostly preliminary data Mar 29 17:37:06 ds2: I will need to research it as well, but ideally BBAI would be the lower-entry platform for hobbyists concerned with DL and CV Mar 29 17:38:41 ds2: It is devilishly hard to find any information on how the EVE's are implemented (or I am having issues :) Mar 29 17:39:23 jduchniewicz1: IIRC, they are not fully documented to the public...others here or maybe jkridner may have resources Mar 29 17:39:29 they == EVE Mar 29 17:40:27 vedant16[m]: We have GCC. I don't think we need LLVM to do a dynamic linker. Mar 29 17:40:53 Student proposals begin today. Seems we are *way* far behind. :-( Mar 29 17:40:55 @ds2 that is what it seems like, I guess they must implement memory in some way (even FPGAs do that) Mar 29 17:41:11 jduchniewicz1: it may be useful to point out what combo of SW are you using for the non accelerated numbers... i.e. plain darknet recompiled, darknet + NNPACK patches, etc Mar 29 17:41:52 ds2: I always used plain darknet, but I may look into other variations on this topic Mar 29 17:43:52 jduchniewicz1: the NNPACK patches made a big difference when I played with it... if you are interested, search for darknet on RPi Mar 29 17:44:58 ds2: I will try experimenting with them to see what possibilities there are Mar 29 17:45:18 jduchniewicz1: btw - I usually get most messages here; esp if you put my nick/handle in the message - just a FYI if I am not immediately active Mar 29 17:45:39 okay Mar 29 17:48:12 ds2: On a different note, how do you imagine doing the acceleration? I have an idea of building something extensible easily -> maybe first accelerating only YOLO(s) and then allowing for more networks Mar 29 17:49:21 ds2: don't know though how it would look like in the whole BB ecosystem, AFAIK here we work on the userspace level and as a middleware for user applications wanting to use DL models Mar 29 17:50:27 ds2: ideally, the user utilizes us as a higher-level wrapper for DL models and we + TIDL or DSP's/NEON acceleration do all the hard work Mar 29 17:51:25 ds2: of course there is a lot of details in implementing that, but I believe having something reusable would be a good addition to the ecosystem Mar 29 17:52:18 jduchniewicz1: I think focusing on YOLO is best given the time available... I see it as a component for other projects Mar 29 17:52:51 for example - a YOLO w/addition training to take input from a camera for a Pick and place machine vision Mar 29 17:53:20 ohh, I am not very well versed with this Mar 29 17:53:42 jduchniewicz1: I think it'll be TIDL + DSP + NEON/ARM combined Mar 29 17:54:27 jduchniewicz1: YOLO is nice for spotting different things in an image and is a bit more efficent then the other networks that do a brute force search on an image Mar 29 17:55:20 ds2: ok, scoping it is important, you are right. I need to read up on all the details and have more data Mar 29 17:55:35 jduchniewicz1: I am not against a nice wrapper but again, time. things that suppose to work according to E2E may wind up taking non trivial amounts of time in practice Mar 29 17:55:58 jduchniewicz1: a convincing and realistic timeframe is an essential part of the proposal Mar 29 17:56:39 ds2: that is true. The wrapper and other nicieties can be done after the project. Mar 29 17:57:30 jduchniewicz1: one thing you should ask other mentors is what is a good upstream for the project... I suspect TI may not take the results back Mar 29 17:59:47 ds2: Wrapping up discussion up to this point. I need to check if the YOLOs will fit on the EVE's (and how to properly manage memory on the devices). Check how much FPS we may achieve with this acceleration in theory. If we can deploy all layers on EVEs or we need DSP/ARM/NEON as well. Educate myself on darknet patches. Mar 29 18:02:42 jduchniewicz1: *nod* just ask if there is anything... may be a few hours before I respond but... just wanted to make sure we have at least an initial contact.. Mar 29 18:02:59 ds2: that is something I had troubles finding on my own. What do you mean about taking back? Merging upstream? I doubt that would be useful for them (or maybe would be...) Mar 29 18:03:24 ds2: of course, this is all very informative so far Mar 29 18:03:57 jduchniewicz1: ideally, we don't want the results to be orphans post GSoC... essentially an end game plan for the results of the work Mar 29 18:04:04 ds2: I just saw there was a previous proposal for this solution for YOLOv2 only Mar 29 18:04:56 anyone seen zeekhuge? Mar 29 18:05:03 ds2: Ah, yes I would very much like this to be useful for others after implementation (no point in coding such things for vain :)) Mar 29 18:05:09 *in Mar 29 18:05:51 jkridner: He seems to be off grid, havenā€™t caught up with him for a while Mar 29 18:05:52 ds2: also I saw that there is YOLOv4, supposedly achieving superior results Mar 29 18:11:00 ds2: just answering one doubt about conv_2d http://downloads.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Machine_Learning/tidl.html Mar 29 18:11:08 it looks like it is already implemented! Mar 29 18:12:22 jduchniewicz1: yes, that was before they did the integration in TIDL... it was suppose to be 'coming soon' when that proposal was written.... YOLOv2 had less layers needing special support Mar 29 18:14:24 jduchniewicz1: Conv2d support need to be checked... esp to see if the kernel sizes are supported Mar 29 18:16:59 ds2: kernel sizes up to 7x7 Mar 29 18:17:26 I will just foolproof it and check it layer by layer :) Mar 29 18:18:23 ds2: there is also the topic of balancing the load evenly but that is probably a topic for a later phase Mar 29 18:19:22 Abhishek https://elinux.org/BeagleBoard/GSoC/2021_Proposal/beagle_config Mar 29 18:19:22 A first draft , needs quotes , suggestions Mar 29 18:20:04 jkridner: do you have any resources regarding EVE's. It would make planning the YOLO deployment easier Mar 29 18:20:45 Looking Mar 29 18:22:36 TI has really tried not to share info about the EVEs. Mar 29 18:23:36 NishanthMenon: is there any chance we can get more information about the EVEs? Mar 29 18:23:59 jkridner, just got invited.. what about EVE? Mar 29 18:24:03 jduchniewicz1: you really have just the TIDL documentation. Mar 29 18:24:29 anything at all. :-D Mar 29 18:24:36 Okay, I will try to infer what can I do with this :) Mar 29 18:24:40 satacker: Can you copy paste your wiki contents in a Google doc and share with me please? Iā€™ll share my email in DM Mar 29 18:25:04 and do you have some experience with them? As discussed earlier I am not sure what are their memory capabilities Mar 29 18:25:09 Iā€™ll add my comments there, you keep the wiki in sync from the doc Mar 29 18:25:10 Yes sure. I'll DM Mar 29 18:25:13 for storing layers of the networks Mar 29 18:25:28 jkridner, need to dig and see.. Mar 29 18:25:35 new GSoC project idea - write an inference engine that takes all the TI docs to synthesize undocumented info based on hints and leaks }:-) Mar 29 18:25:55 šŸ¤£šŸ¤£šŸ˜…šŸ˜…šŸ˜… Mar 29 18:26:00 :-D Mar 29 18:26:49 as long as it was published at one point... Mar 29 18:27:16 ds2, i will be interested in the data as well :D Mar 29 18:28:17 on a less sarcastic note - that strategy may work well on MUSB given all the info scattered between different vendor docs Mar 29 18:29:50 For YOLO, is there a way to integrate at the TIDL level? Mar 29 18:30:04 TI is looking to move away from TIDL even... to Tensorflow Lite. Mar 29 18:30:19 Not sure how YOLO and TFLite relate. Mar 29 18:30:34 They do support TFLite models FWIW Mar 29 18:30:45 There were some TFLite->TIDL integration bits around for AM5729... but I'll have to look for them. Mar 29 18:31:05 But this is disconcerting regarding my proposal šŸ™ Mar 29 18:31:12 https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Machine_Learning/tflite.html Mar 29 18:31:31 jduchniewicz1: I don't really know that much about your proposal. Mar 29 18:32:02 https://elinux.org/BeagleBoard/GSoC/Ideas-2021#YOLO_models_on_the_X15.2FAI Mar 29 18:32:16 It is a slightly modified version of this one Mar 29 18:32:47 ideally with extensible structure for futur Mar 29 18:33:11 Maybe instead of TIDL we should go with the time and use TFLite Mar 29 18:33:19 ds2: what do you think? Mar 29 18:34:09 * jkridner hopes to have a TDA4VM prototype board by the end of May. Mar 29 18:34:57 nevermind, it seems like this is not relevant as it still utilizes TIDL Mar 29 18:35:25 ? Mar 29 18:35:47 YOLO is a model like IMAGENET Mar 29 18:35:50 TFLite utilizes TIDL on AM5729, but, the integration level of TFLite should be more supported moving forward. Mar 29 18:36:19 If you want to battle Tlite, I am okay with that Mar 29 18:36:35 ds2: ok, so as long as a given framework has a way to describe the topology, it can be implemented that way, right? Mar 29 18:36:47 I am probably confused slightly, would using TIDL solely be worse than TFLite? Mar 29 18:36:48 satacker: Thanks, I have your proposal as a Google Doc now Mar 29 18:37:01 tflite and darknet are peers like imagenet and YOLO are Mar 29 18:37:08 Expect responses by tomm evening Mar 29 18:37:09 jkridner: yep Mar 29 18:38:01 jduchniewcz1: TIDL directly may risk long term support issues; but TFlite is a layer built up with TIDL so there is more to chew on to debug Mar 29 18:38:54 ds2: and does TI plan on introducing a successor to TIDL or to stick with a higher level construct like TFLite Mar 29 18:39:23 jduchniewicz1: jkridner is a better person to comment on that Mar 29 18:39:56 because assuming a successful deployment on TIDL it would be just a matter of updating relevant bindings/smaller changes when it is superseded Mar 29 18:40:36 problem with all these is of course model conversion. it becomes essential to document how it was converted to TFLite... YOLO is native to darknet... this is useful for others who retrain the model Mar 29 18:41:01 tflite is another framework... it is less TI proprietary Mar 29 18:41:35 Hmm this is quite fundamental choice Mar 29 18:42:02 tflite can use TIDL from what I am hearing Mar 29 18:42:11 but it is another beast to tame Mar 29 18:42:48 If it TIDL would be alive for 3-5 years from now than it is not that bad Mar 29 18:43:20 my cyrstal ball on that is a cloudy Mar 29 18:43:20 as there can be many iterations over the finished product to finally port it to whatever library Mar 29 18:43:44 yeah, it is eternity in tech world Mar 29 18:44:04 at this point _I_ would be happy to see it run in less then 5 sec per frame with a non tiny model Mar 29 18:44:55 Nevertheless, I will do my homework and address all the previous issues and come back to you tommorow :) Mar 29 18:45:47 'k for some of these, others may be able to help Mar 29 18:45:53 And if jkridner you have more knowledge on the subject of TIDL life expectancy it would make the choice easier Mar 29 18:48:53 Ah I also mentioned the YOLOv4 (more as a nuisance), but a quick search shows it is twice as fast (however is 50% bigger than v3) Mar 29 18:48:54 https://www.seeedstudio.com/blog/2020/06/03/accelerate-yolov4-real-time-object-detection-on-jetson-nano/ Mar 29 18:49:12 @ds2 you might be interested in the subject regardless Mar 29 18:50:06 thanks Mar 29 19:16:55 I thought I'd answered a few times that TI has given me clear guidance they are moving away from TIDL and toward TFLite as the primary API. Mar 29 19:17:10 I didn't mention they are also featuring a Sagemaker NEO interface. Mar 29 19:18:02 TDA4VM is said to only support TFLite and not TIDL, though I suspect it is used under the scenes. Mar 29 19:18:17 BeagleV is also likely to support TFLite. Mar 29 19:22:26 what acc does BeagleV have? Mar 29 19:22:48 tflite can run CPU only Mar 29 19:55:39 https://twitter.com/Jadon/status/1376608236904779779 Mar 29 20:03:25 Hmm thank you. It seems it is quite a quandary then. It would be best to know the community opinion on this then. On one hand having a working implementation on TIDL would be valuable and then only a matter of rewriting in a new framework, but on the other it might be not worth the effort and be totally different on the other APIs Mar 29 20:08:12 m_w: got any FPGA student prospects? Mar 29 20:08:25 * jkridner wonders if there are any lingering students looking to work on Zephyr. Mar 29 20:33:52 I had one person on my discord server that was interested Mar 29 20:34:05 lemme see if that is still the case Mar 29 21:06:43 you mean andrew right ? Mar 29 21:06:53 that's his discord username Mar 29 21:08:56 yeah Mar 29 21:09:09 @vedant16[m], is he still interested? Mar 29 21:10:50 he's here Omkar Bhilare Mar 29 21:11:39 @OmkarBhilare[m], are you still interested in working on Beaglewire? Mar 29 21:12:52 yes, is the task same m_w ? Mar 29 21:14:46 the task would be getting SDRAM working 100% Mar 29 21:14:55 * yes, is the task same m_w ? ( fixed and test the IP blocks related to beagle wire) Mar 29 21:15:06 and possibly working on nmigen support Mar 29 21:15:50 I apparently over did it the first time and we had more dangling issues than I thought Mar 29 21:17:04 I think each peripheral could use a look at and clean up Mar 29 21:17:21 Greg was talking about LiteDRAM on server, is that the way to go for SRAM? Mar 29 21:18:31 I think it would be a good route as that IP has been proven a few times Mar 29 21:18:49 > <@freenode_m_w:matrix.org> the task would be getting SDRAM working 100% Mar 29 21:18:49 * Greg was talking about LiteDRAM on server, is that the way to go for SDRAM? Mar 29 21:24:17 @OmkarBhilare[m], I think nmigen support would be cool as well Mar 29 21:24:46 like Luna or glasgow Mar 29 21:25:48 so we can focus on the SDRAM and maybe shift toward nmigen toward the end Mar 29 21:26:46 but I leave that up to you if you are more interesting on verilog/driver improvements of the current peripherals Mar 29 21:28:53 what about nesting a beaglev in the FPGA? Mar 29 21:30:51 https://github.com/enjoy-digital/litedram/issues/106 Mar 29 21:30:51 This is very old issue but logs proves that it is possible to interface ECP5 with SDRAM. Mar 29 21:31:19 * https://github.com/enjoy-digital/litedram/issues/106 Mar 29 21:31:19 This is very old issue but logs proves that it is possible to interface ECP5 with SDRAM using litedram. Mar 29 21:31:20 @OmkarBhilare[m], I have personally seen it work on ECP5 Mar 29 21:31:47 ds2, how so? Mar 29 21:33:15 maybe beaglev-lite..there is a riscv core that fit that family of FPGAs...even for the icestick Mar 29 21:51:30 ds2, beaglev-lite would be fun Mar 29 21:51:49 we could get picorv32 in there probably Mar 29 21:52:41 that can be a stretch goal maybe Mar 29 23:36:26 https://groups.google.com/g/beagleboard-gsoc/c/JuYr38LR05I surprise! Mar 29 23:36:39 forum moved to https://forum.beagleboard.org/c/gsoc Mar 29 23:36:50 latest messages should be moved shortly. Mar 30 01:53:21 Nice to see FPGA interest **** ENDING LOGGING AT Tue Mar 30 02:59:56 2021