Tuesday, 2016-07-05

*** tpb has joined #timvideos00:00
*** CarlFK has joined #timvideos00:22
*** ChanServ sets mode: +v CarlFK00:22
*** CarlFK has quit IRC01:55
*** CarlFK has joined #timvideos02:01
*** ChanServ sets mode: +v CarlFK02:01
*** aom_ has joined #timvideos02:35
*** sb0 has joined #timvideos03:36
*** sb0 has quit IRC04:18
*** sb0 has joined #timvideos04:44
*** nueces has quit IRC05:10
*** puck has quit IRC05:16
*** puck has joined #timvideos05:19
*** ssk1328 has joined #timvideos05:39
*** aom_ has quit IRC05:40
ssk1328Neuron1k: Thanks for the link, very detailed description. Actually, in my case I had started reading about cache and memory before I started doing any serious programming.05:42
*** sab_123 has joined #timvideos05:42
sab_123mithro, sent an email06:23
ssk1328I just sent a pull request for float16 csc conversion07:37
tpbTitle: Adding float16 conversion by ssk1328 · Pull Request #5 · enjoy-digital/litevideo · GitHub (at github.com)07:38
*** sb0 has quit IRC07:44
*** sb0 has joined #timvideos07:45
*** vystrela_ has quit IRC08:37
*** jea has quit IRC08:38
*** vystrela has joined #timvideos08:45
*** jea has joined #timvideos08:46
_florent_ssk1328: I commented your pul request09:29
ssk1328_florent_:  Thanks!09:29
ssk1328_florent_: Do you have time to look at an error I am getting?09:29
_florent_ssk1328: but in the commit message you have to say why you need that, where you are going to use that09:29
_florent_ssk1328: no what's the error?09:30
tpbTitle: Ubuntu Pastebin (at paste.ubuntu.com)09:30
ssk1328I get this when run make rgb16f2rgb_tb, but don't get this when I run the other make rgb2rgb16f_tb09:31
_florent_strange, I'm not able to locate the error but looking at the code09:35
_florent_what's the reason for introducing floating point here?09:35
_florent_(just trying to understand)09:36
ssk1328For my GSoC project, I need to gamma correct and do other operations on rgb pixel values09:36
ssk1328some of the color correction operations can cause values to temporarily become greater than 1.0 or less than 0.0 and we need to be able to preserve that actual value09:37
ssk1328[0.0-1.0] in float maps to [0-255] in unsigned int09:39
_florent_ok, so this is specific to your project for now09:39
_florent_can we keep that in your project for now and eventually integrate that later?09:40
ssk1328Actually mithro said that its easier to comment and review code by following this09:41
_florent_since thing are still experimental, it's better keeping it in a reparate repo09:50
_florent_we should maybe create a repo for you on https://github.com/timvideos09:51
tpbTitle: Tim Videos Conference Recording Systems · GitHub (at github.com)09:51
_florent_we are working like this with aom: https://github.com/enjoy-digital/hdmi-extenders-gsoc09:52
tpbTitle: GitHub - enjoy-digital/hdmi-extenders-gsoc: HDMI Extenders GSoC project with TimVideos.us (at github.com)09:52
ssk1328Okay, lets see what mithro suggests09:52
_florent_also, I'm wondering if it would not be better to just use 2 look up table to do int to floating point/floating point to int conversion09:54
_florent_16 bits floating point to 8 bits int: 65536x8bits lut / 8 bits int to 16 bits floating point: 256x16bits lut09:55
_florent_and fill this by software09:55
ssk1328_florent_: This can surely be done if we have sufficient memory space and bandwidth to carry out this09:56
ssk1328_florent_: I am not too sure about that09:57
*** sb0 has quit IRC10:13
mithrossk1328: https://github.com/mithro/HDMI2USB-mixing-mask/pull/211:38
tpbTitle: Example RLE code by mithro · Pull Request #2 · mithro/HDMI2USB-mixing-mask · GitHub (at github.com)11:38
mithro_florent_: I'd like to keep it in a pull request for litevideo as this functions will become fundamental to doing all types of proper video mixing, scaling and transforming11:40
ssk1328mithro: Just looking at the code right now11:41
mithrossk1328: It might be possible to do the int8 to float16 with the gamma correction using one 256 entry lookup table11:42
mithroa 65536*16bit lookup table for the reverse seems kind of expensive11:42
ssk1328mithro: Okay. And what about the other way round?11:42
ssk1328mithro: Okay11:42
mithrossk1328: actaully, it might be okay - because anything below 0 should be mapped to 0 and anything above 1.0 should be mapped to 25511:43
_florent_mithro/ssk1328:  do you really need 16 bits floating point?11:43
_florent_mabe you can reduce to 12 bits or less11:44
_florent_mithro: ok to have pull request to litevideo but not for experimental things11:44
ssk1328We are actually not using the complete range provided by float1611:44
mithro_florent_: for color accurate blending, 16bit floating point gives less than -30db noise introduction11:44
_florent_mithro: once things are proven on hardware / with simulation, then ok to integrate that11:45
mithro_florent_: a WIP pull request and stay around for a while why we add comments and stuff to it11:46
mithro_florent_: I guess I can get him to send the pull request to my repo, but we will still need your comments on the code11:46
_florent_if it stay as a pull request until we fix things and get things done correctly then ok11:46
mithro_florent_: yes, the pull request is just a place to keep comments all together11:47
_florent_ok, no problem then11:48
mithro_florent_: great!11:50
mithro_florent_: ssk1328 has a bunch of documentation on how 16bit floats will end up being implemented in the FPGA11:51
mithrossk1328: do you want to share them?11:51
ssk1328_florent_: Here it is https://docs.google.com/document/d/1684Tn4aeWxeelCvrJ5maKJoShtlIRolC2oq0c4_4A7k/edit#11:51
tpbTitle: Design Document on 16bit Floating Point - Google Docs (at docs.google.com)11:51
*** Bertl_zZ is now known as Bertl_oO11:51
ssk1328Still work in progress11:51
_florent_ssk1328: thanks12:01
mithrosab_123: you do know you can view the diff that I will view at https://github.com/mithro/fx2lib/pull/17/files right?12:04
tpbTitle: Created a UART API definition by RacingTornado · Pull Request #17 · mithro/fx2lib · GitHub (at github.com)12:04
sab_123mithro, yes12:05
mithrosab_123: so you can view that and then see if there is anything I might find wrong with it too12:06
sab_123mithro, forgot to remove that12:06
sab_123I checked it now12:06
sab_123I compile it to test if the header is okay12:06
sab_123In the sense, does it compile12:06
sab_123Usually I remove it12:06
mithrosab_123: Also, I'd like you to think more about the consequences of your comments in documentation12:07
mithrosab_123: If you saw something like "Enum values greater than 0 are supported.", you could get the impression that all uarts support all the enum values12:08
mithrosab_123: you also need to think about the context, is something system level, uart level, api level or implementation level, etc12:09
mithrosab_123: Think of all the different ways people might misinterpret your comments too12:09
sab_123mithro, ok12:09
mithrossk1328: it looks like you haven't pushed updated commits for the heartbeat yet?12:33
mithrosab_123: "Unless you know what you doing" is a useless thing to say12:34
sab_123mithro, how would you like me to word it then12:35
mithrosab_123: Explain to me why they shouldn't use them?12:35
sab_123mithro, basically the end user shoudnt use those values12:35
mithrosab_123: then why do they exist?12:35
sab_123Mainly because the baud rate is not standard12:35
mithrosab_123: so?12:36
mithrosab_123: If the user requested a non-standard baud rate and it is documented that you might get a non-standard baud rate, then everything is good12:36
sab_123And you would have to setup software in the system(ex: minicom doesnt support anything other than standard ones)12:36
sab_123gtkterm doesnt either12:36
mithrosab_123: So, what is the issue you are trying to prevent then?12:37
sab_123The only way to see those rates is to hook up those lines using a scope ..12:37
sab_123Or some software which I havent yet used which supports non standard baud12:37
mithrosab_123: BAUD_FASTEST will give you the fastest baud rate the UART can operate, this may be a non-standard baud rate, you can use XYZ to get the actual set BAUD rate.12:38
mithrosab_123: Or12:38
mithrosab_123: BAUD_FASTEST will give you the fastest baud rate the UART can operate at. WARNING: This is allowed to be a non-standard baud rate.12:39
sab_123mithro, I will put that in12:39
mithrosab_123: You should be now thinking, "should BAUD_ANY give you a non-standard baud rate"?12:39
mithrosab_123: should there be a "BAUD_FASTEST_STANDARD" which gives the fastest standard baud rate?12:40
mithrosab_123: The API only currently lets you get standard baud rates, but a non-standard baud rate can be set via BAUD_FASTEST, do we need an API function which returns the actual baud rate as an uint16_t or something?12:41
sab_123mithro, it returns BAUD_FASTEST12:41
sab_123setting and returning are the same enum12:41
mithrosab_123: do you see a problem there then?12:41
mithrosab_123: Calling "set_baud_rate(BAUD_FASTEST)" and then having "get_baud_rate()" return BAUD_9600 seems like a pretty reasonable and useful API12:42
sab_123mithro, I dont get that12:43
sab_123BAUD_FASTEST would be mapped to one of the bauds12:43
sab_123in the enum12:43
sab_123I just return that12:43
sab_123BAUD_FASTEST in uart0 gets mapped to 960012:43
sab_123so the enum is automatically set to 960012:44
mithrosab_123: yes12:44
mithrosab_123: but you can't redefine BAUD_FASTEST to the same value as 9600 as that would affect giving uart112:44
sab_123it wont12:45
sab_123they are no different enums12:45
mithrosab_123: that isn't how the API is define right now12:45
mithrothere is one BAUD_FASTEST define in the api code12:46
sab_123that just the enum12:46
mithroI have to go12:47
mithrosab_123: show me how it works, your documentation can't be up to scratch because we don't seem to be understanding each other12:47
tpbTitle: fx2lib/soft_uart.h at 82ae21829baf26985656fb57c67761c5ca48a721 · RacingTornado/fx2lib · GitHub (at github.com)12:47
sab_123For every uart which is created, I create that enum12:49
sab_123The just return that same enum12:49
sab_123so if uart0 is used, the uart0 enum will return12:49
sab_123for uart1, the uart1 enum will return12:49
tpbTitle: fx2lib/soft_uart.h at 82ae21829baf26985656fb57c67761c5ca48a721 · RacingTornado/fx2lib · GitHub (at github.com)12:50
sab_123I will set the baud rate there12:50
*** shenki has quit IRC13:27
*** shenki has joined #timvideos13:39
*** ChanServ sets mode: +v shenki13:39
*** nueces has joined #timvideos13:46
*** ssk1328 has quit IRC14:34
*** G33KatWork has quit IRC14:37
mithro_florent_: quick ping? I'm just heading to bed but wanted to share something with you before I did14:51
_florent_yes I'm here14:52
tpbTitle: lite ecosystem - Google Drawings (at docs.google.com)14:53
mithro_florent_: I was thinking about how to do the CI for all your lite stuff14:53
mithro_florent_: and that is my proposal for how you should structure things14:54
mithro_florent_: also interested in making it easier to share stuff from the HDMI2USB-misoc-firmware and "upstream"14:54
_florent_mithro, thanks, that's interesting :)14:55
mithro_florent_: Have a thing about it and we can discuss details more later in the week14:56
cr1901_modernI wonder what the minimal component liteSATA board is...14:56
_florent_not sure we should split litesoc/litevideosoc/litesoclinux14:56
_florent_this can simply be litesoc14:57
mithro_florent_: But I'm obviously invested in getting lite modules into the position that you have other contributors and always improving code quality+productivity :)14:57
_florent_but what I see is that it seems to solve some of the inter-dependency14:57
cr1901_modernmithro: I'm familiar with litescope FWIW14:57
mithroI think litesoclinux would just be litesoc + the linux tooling side of things (IE linux kernel, linux user space, etc)14:58
_florent_yes but we can probably have all that in a single repo I think, no?14:58
mithro_florent_: well, it depends on if people are going to continue to use litesoc without Linux14:59
mithro_florent_: It's more attractive if you don't have all this extra stuff lying around which you don't use14:59
_florent_yes I can understand, let's think about that and discuss that later15:00
mithroIt might make sense to merge litesoc and litevideosoc - I was thinking that litevideosoc would be a reduced set of boards with more functionality - IE if a board is in litevideosoc it will minimally do a set of things15:00
mithroI can imagine someone wanting a litesoc-rtems maybe :)15:01
_florent_cr1901_modern: for LiteSATA, a nexys_video15:01
_florent_or KC70515:01
_florent_or the opsis15:01
mithro_florent_: There is SATA on the nexys_video?15:01
cr1901_modernThat later one is $3000!!15:01
mithro_florent_: or an FMC board?15:01
cr1901_modernThe KC705*15:01
_florent_you only need a transceiver15:02
_florent_and find a way to connect it to a SATA cable15:02
_florent_yes the KC705 is expensive15:02
cr1901_modernWhat prevents someone from making a PMOD Sata connector?15:02
mithrocr1901_modern: The GTP transceivers are not broken out to the PMOD connectors normally...15:04
_florent_I haven't seen PMOD connectors connected to transceivers15:04
cr1901_modernOh, the required transceivers are on specific pins...15:04
mithroAlthough, SATA 1.0 is only 1.5 Gbit/s -- the Artix-7 can do that on its normal pins with a bit of coaxing....15:05
cr1901_modernI don't think I have any boards/FPGAs with the proper transceivers... I thought it was LVDS for some reason15:05
cr1901_modernUnless minispartan can do SATA 1.015:06
mithrocr1901_modern: It is LVDS, just very high speed LVDS15:06
mithroSATA 2.0 is 3Gbit/s - SATA revision 3.2 is 16 Gbit/s!15:07
cr1901_modernSo Xilinx et al provides a special LVDS transceivers? As opposed to HMDI which can get away with a "basic" LVDS setting?15:07
mithrocr1901_modern: the high speed transceivers - GTP and GTX15:08
mithrocr1901_modern: the Opsis has them, broken out on the DisplayPort connectors15:08
cr1901_modernI guess minispartan doesn't need them/use them15:09
mithrocr1901_modern: yeah, it's why it can only do 720p60 or 1080p3015:09
cr1901_modernOh, I thought that was b/c of the shitty SDRAM bandwidth :P15:09
mithrocr1901_modern: https://docs.google.com/document/d/1noNqTdLYlEru_6gWOlFqFvYe-vctUE23Tp42oRoKKKo/pub15:10
tpbTitle: Numato Opsis - Video Information FAQ (at docs.google.com)15:10
mithrocr1901_modern: no, that is how fast the IO pins can toggle15:10
cr1901_modern_florent_: Perhaps I got confused by what you meant by minispartan's "SDRAM woes"?15:11
mithrocr1901_modern: it also has SDRAM woes :P15:11
mithroI should be asleep15:12
cr1901_modernIs GTP enabled by placing the correct constraint in the UCF?15:12
cr1901_modernOh sorry... too many q;s15:12
mithro_florent_: I'll try and reply to your other email tomorrow15:12
cr1901_modernno worries, I'll figure it out later15:12
mithrocr1901_modern: go read my FAQ15:13
mithrocr1901_modern: any luck with the frequency counter?15:13
mithrognight -- I'l read the scrollback :)15:13
cr1901_modernmithro: No, I've been swapping between your work and m-labs work15:14
cr1901_modernmithro: I have a few things I haven't tried, but I won't be able to get much done if my display driver keeps crashing b/c it doesn't like the board.15:15
cr1901_modernI'll probably try hamsterwork's minimum-component demo as a last resort. If that crashes my display driver, then my machine/driver is at fault. I'll need to buy a separate machine for testing then.15:16
*** sab_123 has quit IRC15:17
cr1901_modernmithro: Current status report... I'm under the impression that the freq counter works, but my machine doesn't like the minispartan and is refusing to send it good data/clk.15:17
cr1901_modernmithro: I'll probably buy (another :P- got PocketCHIP as a bday gift) one of these as a last resort (with an HDMI daughterboard) https://getchip.com/pages/chip15:19
tpbTitle: Get C.H.I.P. - The World's First Nine Dollar Computer (at getchip.com)15:19
*** G33KatWork has joined #timvideos15:31
*** ssk1328 has joined #timvideos16:37
ssk1328mithro: heartbeat pull request was already updated with all the necessary changes made16:59
ssk1328mithro: Also logged an issue for volatile usage https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/26717:00
tpbTitle: Clean up the usage of volatile in the lm32 firmware · Issue #267 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com)17:00
ssk1328mithro: Not sure how to add labels here, maybe I don't have the permissions17:00
*** ssk1328 has quit IRC20:24
*** Bertl_oO is now known as Bertl_zZ21:50
*** nueces has quit IRC21:51
*** nueces has joined #timvideos22:23
*** nueces has quit IRC22:35
mithromorning people22:50
mithroDidn't actually sleep at all last night :(22:50
mithrocr1901_modern: maybe get a RPi?22:50
mithrocr1901_modern: They are cheap and tends to ignore EDID information even when you want them to read it :P22:51
*** nueces has joined #timvideos23:33
nuecesmithro, hi, I'm testing the camera output with a hdmi tv and it works at 720p23:34
tpbTitle: dpaste: 3T37N39 (at dpaste.com)23:34
CarlFKnueces: I would test with the most recent firmware23:39
nuecesI'm compiling it to test23:40
CarlFKnueces: https://github.com/timvideos/HDMI2USB-firmware-prebuilt23:41
tpbTitle: GitHub - timvideos/HDMI2USB-firmware-prebuilt: Prebuilt firmware for the HDMI2USB devices (such as the Numato Opsis and the Digilent Atlys board) and OS drivers. (at github.com)23:41
CarlFKI hear the same source code doesn't produce the same binary, so it is probably better to use the same binary (right?  who thing seems kinda wonky to me)23:42
*** nueces has quit IRC23:48
*** nueces has joined #timvideos23:49
cr1901_modernOh I do have an RPi... come  to think of it. But no wifi dongle :( (It's a model A)23:57
nuecesI compiled and load the latest firmware and the output in the tv now is displaying an image23:57
nuecesbut with the same problem that the other dat23:57
tpbTitle: dpaste: 2SPV21K (at dpaste.com)23:58

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!