| --- Log opened Fri Sep 12 00:00:48 2014 | ||
| poke53281 | stekern: mplayer works too. Any ideas for a 1-2MB video? Of course I can simply take a cat video from youtube :) | 01:03 |
|---|---|---|
| sb0 | so, why did that binary grow to 5MB while doing exactly the same? that's 10x the memory capacity of the atari st | 01:21 |
| poke53281 | because of the c conversion in between | 01:52 |
| poke53281 | every 68k opcode must be translated to pure C code. And the compiler translates this to openrisc. | 01:53 |
| poke53281 | Hmm, playing h265 videos isn't fun. But the compression ratio is so good. | 03:37 |
| stekern | poke53281: mpeg1 is maybe more realistic? | 04:44 |
| poke53281 | At the moment the problem seems to be the resolution and not the codec. | 04:55 |
| poke53281 | mpeg1, mpeg2, h264. The speed differ not that much. | 04:55 |
| poke53281 | But e. g. scaling to fullscreen is not possible. | 04:55 |
| stekern | hmm, ok | 05:00 |
| stekern | can't you play it unscaled? | 05:00 |
| poke53281 | I can. But I use videos with the correct resolution, they are also too slow. | 05:01 |
| poke53281 | I think, it's the yuv->rgb conversion | 05:02 |
| stekern | I see | 05:02 |
| poke53281 | 640x400x25 = 6400000 conversions per second. How many instructions do you need? | 05:03 |
| poke53281 | I have only around 50MIPS. So, a smooth fullscreen is not possible. | 05:04 |
| poke53281 | they use even bicubic interpolation if I scale this up. | 05:04 |
| stekern | mmm, I remember that 320x200 MPEG1 was barely watchable on a 166MHz pentium | 05:07 |
| poke53281 | Are you sure. | 05:07 |
| poke53281 | Wing Commander 4 was playabler on a 486 and had full screen mpeg2 movies. | 05:07 |
| poke53281 | Of course assembler optimized code. | 05:07 |
| stekern | well, I was watching VCD's on that computer, and it worked, SVCD's didn't | 05:11 |
| stekern | (so the resolution was actually 352x288 or something) | 05:11 |
| poke53281 | Possible | 05:20 |
| poke53281 | wing commander used also some tricks like showing only every second line if svga was on. | 05:22 |
| poke53281 | I converted around 20 movies to test, which format is the best. No result so far. | 05:26 |
| stekern | isn't it legal to bitreverse a vector like this in verilog: b[31:0] = a[0:31]; | 05:37 |
| stekern | ? | 05:37 |
| poke53281 | Don't ask me | 05:38 |
| dalias | poke53281, dropping to bilinear scaling could help (and is arguably better quality anyway) | 05:39 |
| dalias | ideally you don't want to scale at all, but you have to do colorspace conversion and scaling of the chroma planes which are sampled at half the rate | 05:40 |
| poke53281 | I tried a few things like this "-sws 4" for example. But didn't change anything | 05:46 |
| poke53281 | dalias: I hae updated my official version. http://s-macke.github.io/jor1k/?user=Rql21SGXB4 | 05:58 |
| poke53281 | two videos are in /usr/share/mplayer | 05:59 |
| poke53281 | If you can find good parameters to watch the videos in fullscreen would be fantastic. | 05:59 |
| stekern | poke53281: but the fact that mplayer works (but not fast enough) is still good news IMO | 06:01 |
| poke53281 | Yes, good news. | 06:02 |
| poke53281 | Interesting is, that mpeg4 videos seem to use the floating point numbers. | 06:03 |
| stekern | we just need a fast enough implementation for it ;) | 06:03 |
| poke53281 | The codec is a factor of two slower with soft float | 06:03 |
| stekern | ...but it gives new interest angles to hw accelerated videos etc | 06:03 |
| stekern | *interesting | 06:03 |
| stekern | and I can use that once I got audio working on my sockit board ;) | 06:04 |
| poke53281 | what about a real graphic card with layers and hw supported color conversion. | 06:04 |
| poke53281 | Yes, you can use it. I can give you a soft-float version if you want. | 06:05 |
| poke53281 | Or just the compile script | 06:05 |
| stekern | that'd be nice | 06:06 |
| poke53281 | wait, I have to add one sed. | 06:06 |
| stekern | but that mpeg1 video isn't all *that* bad, I was expecting worse. Like 0.25 fps or something | 06:06 |
| stekern | that looks like at least 5-6 fps | 06:07 |
| poke53281 | No, I use only 60-70% of maximum performance of my cpu. | 06:07 |
| poke53281 | So, the cpu is idle when you watch the video. | 06:07 |
| stekern | and this is on this crap i3 laptop | 06:08 |
| poke53281 | you should also change the fps at the bottom of the terminal. | 06:08 |
| poke53281 | It seems that the effort to decode mpeg1 and mpeg4 is only a factor 2 or 3 different. | 06:10 |
| stekern | I want to explore this https://github.com/jbush001/GPGPU and this https://github.com/asicguy/gplgpu at some point | 06:11 |
| poke53281 | do we need Xorg and Linux drivers for this? | 06:18 |
| poke53281 | http://pastie.org/9547147 | 06:22 |
| poke53281 | stekern: this is the first part. | 06:22 |
| poke53281 | and the soft-float mplayer.tar.bz2 you can find here: jor1k.com/packages/ | 06:24 |
| poke53281 | compiled for SDL and fbdev | 06:24 |
| poke53281 | if you want direct X support (not via SDL) you have to compile it yourself. | 06:25 |
| poke53281 | stekern, dalias : If you have an idea for a nice 1-2MB video, please tell me. No funny cats please. | 06:27 |
| poke53281 | youtube link is Ok. | 06:28 |
| poke53281 | but not more than 1 minute. | 06:29 |
| stekern | sorry, I've got no good video-clip advices | 06:46 |
| poke53281 | some short animation movie? The add from Apple in the year 1984? | 06:48 |
| poke53281 | But one thing is sure. I need sound :) | 06:49 |
| poke53281 | you know what it means, to time sound in Javascript? And this together with an emulated machine? | 06:50 |
| poke53281 | Quantum mechanics is easier. | 06:51 |
| poke53281 | By the way. There is a good chance that I will join the orconf in Munich. | 06:55 |
| poke53281 | i am in stuttgart during that time | 06:55 |
| olofk | stekern: Yeah, I'm interested in those GPU projects as well. I'm also curious about the h264 project on opencores | 07:13 |
| olofk | poke53281: That's really good news. Hope you can make it there | 07:14 |
| stekern | olofk: do I remember wrong that you wrote a l.ror test? | 07:14 |
| olofk | stekern: No, I'm pretty sure I did that | 07:14 |
| poke53281 | h264 project? | 07:14 |
| stekern | I can't seem to find that we would have any test for that | 07:14 |
| olofk | poke53281: http://opencores.org/project,oc-h264-encoder | 07:15 |
| olofk | Don't know any more about it though | 07:15 |
| olofk | stekern: I see what I can find here | 07:15 |
| olofk | aha. I have it here locally at least | 07:16 |
| olofk | http://pastebin.com/hnqUYjju | 07:17 |
| olofk | It's extremely comprehensive | 07:18 |
| poke53281 | Hmm, nowadays video encoders are basically ARM cpus(or any other cheap cpu) with a lot of fixed function units. Am I wrong? | 07:18 |
| olofk | I have no idea, but that sounds reasonable | 07:19 |
| poke53281 | Otherwise it makes no sense. The complexity is too high to make it different. You have internal memory and a flash with the firmware for the controller cpu. | 07:20 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/ccdb61379193b1933036f3162deb8cf252c52390 | 07:21 |
| mor1kx | mor1kx/master ccdb613 Stefan Kristiansson: execute_alu: optimize barrel shifter... | 07:21 |
| stekern | olofk: great, now I can actually test that ^ change too ;) | 07:22 |
| poke53281 | olofk: I ask this, because I wonder, what this project should be at the end. | 07:22 |
| stekern | well, I did test the shift ops, and they work | 07:22 |
| olofk | stekern: Looks like I didn't push everything in wb_streamer yesterday | 07:23 |
| poke53281 | Just the fixed function units or together with controller(openrisc?) and firmware? | 07:23 |
| stekern | olofk: mind committing that to https://github.com/openrisc/or1k-tests? | 07:23 |
| olofk | Sure | 07:23 |
| olofk | poke53281: This project = openrisc in general? | 07:24 |
| poke53281 | I am talking only about the h264 project. How do they want to implement it. | 07:24 |
| olofk | poke53281: I think that project is dead. There was some talk about it when I joined the project, but nothing since. I'm just thinking we could scavenge it for useful parts :) | 07:26 |
| stekern | that new barrel shifter is a lot smaller than the old one, it's also still smaller than the old one with l.ror enabled in the new one and disabled in the old | 07:26 |
| olofk | stekern: That's how you make sb0 happy :) | 07:27 |
| stekern | well, it was actually a #m-labs guy, Florent Kermarrec, that hinted on the implementation | 07:28 |
| olofk | haha | 07:28 |
| stekern | apperantly that's how LM32 does it, but I didn't really look at their code, it was pretty straight forward from his description | 07:29 |
| stekern | but I'm also pleased that in the end, the implementation also became a lot cleaner than the original with a lot of code duplication | 07:31 |
| sb0 | stekern, excellent, thanks | 07:32 |
| sb0 | let me try that | 07:32 |
| olofk | Is the barrel shifter mandatory? Some of the shift operators are optional, but not all of them, right? | 07:32 |
| stekern | sb0: a word of warning, (as I mentioned in #m-labs) the other thing florent hinted on *added* some LUTs... beats me why ISE hated that... | 07:33 |
| olofk | stekern: Any ideas for a nice clean wishbone slave with a few registers that I can get some inspiration from? | 07:35 |
| stekern | olofk: we have a serial shift implementation too | 07:36 |
| sb0 | overall FPGA utilisation went down a few %, so it's moving in the right direction nevertheless | 08:00 |
| olofk | stekern: | 08:41 |
| olofk | There's a wb config interface for the stream writer now as well | 08:42 |
| stekern | olofk: why, oh why did you add a _m_ to the data/valid/ready signals??? | 09:24 |
| stekern | it screwed up my tab amount to line up the signals in the instantiation | 09:25 |
| olofk | Sorry :( | 09:53 |
| olofk | m for master. It's a master port that sends data | 09:53 |
| stekern | yeah, I got that | 09:55 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/64bf7e10a8e3d14e47e676209a476bf2c84d366b | 09:58 |
| mor1kx | mor1kx/master 64bf7e1 Florent Kermarrec: mor1kx_store_buffer: avoid unnecessary subtractor | 09:58 |
| olofk | mor1kx is on fire with new commits now | 09:58 |
| stekern | yes, I heard that that guy with a beard had mentioned an openrisc core starting with 'm' on some conference, so I thought it might be good to keep up the appearance that there's activity in the repo if someone goes look there ;) | 10:02 |
| olofk | I also said it was a multi-issue, out-of-order 128 bit CPU, so you might have some work to do here :) | 10:04 |
| stekern | well, if it can be out-of-order, I can easily give you such a 128-bit multi-issue implementation - https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcQoY9VsTBBGBKiBG8jbkja2xEDv_d22aWgiqybthke2cWsXkxSscaRwOt_8 | 10:07 |
| olofk | haha | 10:08 |
| olofk | I like the implementation, but we should change the color | 10:11 |
| stekern | wb_streamer builds now, so feel free to ship it | 10:14 |
| olofk | woohoo | 10:14 |
| olofk | Icarus is quite a lot faster than the free modelsim version | 10:17 |
| olofk | 14s versus 24s when running 10000 transactions in wb_streamer | 10:19 |
| olofk | stekern: Does it really build? I noticed that some of the wb signals had wrong size and direction | 10:24 |
| olofk | But I pushed fixes for that | 10:24 |
| stekern | ok, but it did build without that | 10:25 |
| olofk | They were probably optimized away at an early stage | 10:35 |
| olofk | So if I add an IRQ, this should be ready for basic usage I guess | 10:35 |
| stekern | yes, that's at least enough for my needs | 10:36 |
| olofk | So how would one use this? Write data to an area, press enable, write to another area and update the start address on interrupts? | 10:41 |
| olofk | Running tests on different buffer sizes will be next. Especially the corner cases of small buffers | 10:42 |
| stekern | olofk: tbh, I'm not entirely sure what's the best, but that sounds like an option at least | 10:43 |
| olofk | First idea was to add read/write pointers to be able to implement a circular buffer, but this is easier | 10:44 |
| stekern | olofk: don't ship, it doesn't build anymore | 10:47 |
| stekern | ah, I had made an error in the instantiation | 10:49 |
| olofk | Did you pull my latest changes? | 10:50 |
| olofk | You need to update orpsoc-cores as well in that case to run simulations | 10:50 |
| stekern | simulations? | 10:51 |
| stekern | straight to ASIC, that's how real men do it | 10:51 |
| stekern | I'm trusting that my supplier have verified their cores, is that unwise? | 10:52 |
| olofk | Of course, but I mean when you simulate the ASIC in your web browser | 10:52 |
| stekern | ah | 10:53 |
| olofk | hmm... buffer size currently has to be a multiple of the burst length | 11:00 |
| olofk | Easiest fix. Always require buffer size and burst length to be power of two | 11:00 |
| olofk | But I'm not sure if that's a good restriction | 11:01 |
| stekern | what does 'burst length' mean in this context? | 11:08 |
| olofk | As I don't want to hog the bus to read out the complete buffer in one transaction, I'm doing shorter bursts instead | 11:09 |
| stekern | isn't that a job for the arbiter to decide? | 11:10 |
| olofk | As long as cyc is raised, I don't think that the arbiter is allowed to interfere | 11:10 |
| stekern | ah, right, there's no fixed length on the linear bursts | 11:11 |
| olofk | Nope | 11:11 |
| stekern | but requiring that to be a power of 2 doesn't seem like a crazy restriction | 11:11 |
| olofk | No, but I want to figure out what causes the least amount of corner cases | 11:12 |
| olofk | I've pretty much decided on at least requiring burst lengths to be power of two. | 11:15 |
| olofk | But I probably need to add arbitrary buffer sizes | 11:15 |
| olofk | But that opens up some corner cases, so that will have to wait for a bit | 11:16 |
| stekern | hmm, maybe you can solve that in some other way | 11:19 |
| stekern | but is that a runtime or compile time option? | 11:21 |
| olofk | It's runtime, with a compile-time maximum | 11:22 |
| olofk | buf size that is | 11:22 |
| stekern | well, can't burst size be runtime too? | 11:23 |
| olofk | It is | 11:23 |
| stekern | good | 11:23 |
| stekern | then it's probably not a problem if the buf size has to be a multiple of the burst size | 11:24 |
| olofk | I think I'll encode burst length as 2^value in the register to ensure that I always have a good value there | 11:24 |
| stekern | and no problem that burst size has to 2^ | 11:24 |
| stekern | +be | 11:25 |
| olofk | But then the user/driver has to make sure that these conditions are fulfilled. Sounds risky to me | 11:26 |
| stekern | if you need some odd transfers, then you can do bursts down to 1 | 11:26 |
| olofk | Yes, but that doesn't work either with the current logic :) | 11:26 |
| olofk | Two might work | 11:26 |
| stekern | no, but that sounds like something that would be easy to implement without corner cases | 11:27 |
| olofk | Yes, sure. That must work eventually | 11:27 |
| stekern | I think reasonable restrictions that the user/sw needs to follow is less risky than potentially buggy hw implementations ;) | 11:28 |
| olofk | True | 11:28 |
| stekern | and the cost of fixing buggy sw is usually cheaper than fixing buggy hw | 11:28 |
| olofk | But if I want to send a 268 byte packet, I don't want to send 256 byte, then 8, and then 4 and having to update burst size for the smaller buffer sizes | 11:30 |
| olofk | But fixing buf size = 1 will take care of most of the problems actually | 11:32 |
| olofk | Or actually buf size = 4, since it is specified in bytes | 11:48 |
| PaulfraOSAA | Just a quick question, mor1kx is "just" a newer version of orpsoc, and I can use that instead of orpsoc when setting up? | 17:42 |
| PaulfraOSAA | Ok, I asked too soon, aparently not | 17:43 |
| PaulfraOSAA | Sorry about that | 17:43 |
| stekern | mor1kx is a cpu core, orpsoc is/was a reference SoC | 18:00 |
| PaulfraOSAA | Yeah, but the orsop-cores imports mor1kx, so I clone the two repos (orsopc-cores and fusesoc) and I should be ready to go (if i've got the cross complier chain in place) right? | 18:03 |
| stekern | right | 18:04 |
| PaulfraOSAA | That's the danger of having the IRC channel open while downloading: Your'e tempted to start asking questions prematurely :) | 18:12 |
| olofk | PaulfraOSAA: There's a new fancy feature in fusesoc that makes it a tad easier to set up. Just run 'fusesoc init' after you have installed fusesoc | 18:15 |
| PaulfraOSAA | that will do what exactly? Install the orsop-cores as well? | 18:16 |
| PaulfraOSAA | BTW Mike might have said that going from VHDL to Verilog is much easier, I pitty the fool that goes the other way then... | 18:17 |
| olofk | Yes, and write a configuration file that will make fusesoc find orpsoc-cores automatically | 18:17 |
| olofk | :) | 18:17 |
| olofk | No one does :) | 18:17 |
| PaulfraOSAA | They should, It's far better for systems programming | 18:17 |
| olofk | Yes, it is, but otoh system verilog is probably a better choice for that | 18:18 |
| PaulfraOSAA | During our thesis project we came over a cordic that really should have been paramereized, the authors had given up on doing it in verilog, it took me half a day to port and implement parametrization | 18:18 |
| PaulfraOSAA | (that was in the gnu radio ettus radio project) | 18:19 |
| olofk | Many older cores uses `define instead of proper parameters | 18:19 |
| olofk | btw, check out https://github.com/steveicarus/iverilog if you want to see the current level of VHDL support in Icarus verilog | 18:20 |
| PaulfraOSAA | You mentioned, and I saw some places on the web that you had done a LX9 port, but I can't find it anywhere | 18:20 |
| olofk | Ah no. I never pushed it. I should do that | 18:21 |
| olofk | But it might need some cleaning up first | 18:21 |
| PaulfraOSAA | You really should, I don't want to install quartus just to put it on my de1 board, if the build files are there for lx9 :) | 18:22 |
| olofk | Problem with the lx9 is that you need an external JTAG debugger to connect to the CPU since the JTAG protocol through USB hasn't been reverse-engineered yet | 18:23 |
| PaulfraOSAA | I also thought about it, it might be that it is actually the Xilinx simulation tool and not the modelsim that allows multilanguage simulation | 18:23 |
| olofk | Xilinx ISIM doesn't support VPI, so it's unfortunately quite useless for many of the OpenRISC-based systems | 18:24 |
| olofk | But yes, you might be right that it at least supports mixed-language | 18:24 |
| PaulfraOSAA | Yeah, you could skip the part of the sentence beginning with for... | 18:25 |
| olofk | :) | 18:25 |
| olofk | I tried to build my lx9 system, and it still builds. I can send you the bit file if you want. Unfortunately I have no idea if it does anything useful. In best case it might blink some LEDs :) | 18:26 |
| olofk | (but probably not) | 18:26 |
| PaulfraOSAA | iverilog looks very much like ghdl (from the readme) | 18:27 |
| PaulfraOSAA | Would it be possible to fit a bare bone system with an Ethernet peripheral on there + room for custom code? | 18:28 |
| PaulfraOSAA | Or is that (still??) pushing the 200% utilization envelope? | 18:28 |
| olofk | _franck__: Didn't you add some basic support for running ghdl under fusesoc a while ago? | 18:28 |
| olofk | PaulfraOSAA: I haven't tried it since then, but I don't think it should be impossible. | 18:29 |
| olofk | I think the big problem back then was that it failed to use Block RAMs efficiently | 18:30 |
| olofk | mor1kx+UART+debug stuff fits ok, so maybe we could try to add minimac if a full ethmac doesn't fit | 18:31 |
| PaulfraOSAA | Cool, I have a crazy idea and I want to use as much open hardware for it as possible, | 18:31 |
| olofk | I haven't used minimac though, but sb0 might have some info here | 18:31 |
| olofk | PaulfraOSAA: Bitcoin mining? ;) | 18:31 |
| PaulfraOSAA | Yep, as a hackerspace workshop, named after Mike Dini :) I got his permission at the conference | 18:32 |
| olofk | haha | 18:32 |
| olofk | We should launch DiniCoin | 18:32 |
| PaulfraOSAA | LOL | 18:35 |
| olofk | Got to run now, but here's a snapshot of the LX9 Microboard port if you want to take a look at it | 18:36 |
| olofk | https://www.dropbox.com/s/aj6vui1hn098ukm/lx9_microboard.tar.gz?dl=0 | 18:36 |
| PaulfraOSAA | tnx | 18:36 |
| PaulfraOSAA | olofk: Should you read the log, I succeeded in making all four red leds blink at about 1Hz, so if that is a sucess criterion, whell then yay :) | 19:00 |
| _franck__ | olofk: ghdl support for fusesoc is on my TODO list. I just started to play with GHDL and it's VHPI feature, nothing more. | 19:25 |
| PaulfraOSAA | _franck__: does ghdl support verilog? Isn't that just substituting one problem for another? Or is the idea to be able to simulate both vhdl and verilog? | 20:00 |
| -!- PaulfraOSAA is now known as exparrot | 20:05 | |
| olofk | exparrot: It only supports VHDL, but it's nice to have support for all major Open Source simulators | 20:10 |
| exparrot | olofk: my or1k asm is not all too sharp, but it seems the blink pattern is wrong, all leds lit up at the same time. | 20:12 |
| exparrot | But it was easy to do :D | 20:12 |
| exparrot | On the build instructions for the newlib toolchain, there is a _lot_ of --disable-xxx, why would I want to disable stuff like gdb? | 20:19 |
| exparrot | http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 <- this instruction | 20:20 |
| olofk | exparrot: Is the led blinker on the lx9 or the de1? | 20:42 |
| exparrot | The one on the lx9 | 20:42 |
| olofk | c00l | 20:42 |
| exparrot | I haven't got Quartus set up XD | 20:42 |
| olofk | Regarding the disable stuff, you can probably enable gdb in the first pass | 20:43 |
| olofk | Yeah, I remember trying that about a week ago | 20:43 |
| exparrot | Yeah, I'm doing it the hard way and pretty tired | 20:45 |
| exparrot | I just hope i don't fsck up my box | 20:45 |
| olofk | No worries. It shouldn't touch anything outside of --prefix | 20:45 |
| olofk | FuseSoC on the other hand installs a browser toolbar and a live background | 20:46 |
| exparrot | did you notice the thing about tired? ;) | 20:46 |
| exparrot | :P | 20:46 |
| olofk | ah yes. Tiredness has a tendency to make things worse than they have to be :) | 20:46 |
| exparrot | Also, I go to and from... need to pack a backpack for tomorrow | 20:47 |
| olofk | Well, compiling toolchains generally leave you with a lot of spare time | 20:48 |
| olofk | Has everyone registrered for orconf btw? | 21:00 |
| --- Log closed Fri Sep 12 21:46:24 2014 | ||
| --- Log opened Fri Sep 12 21:46:41 2014 | ||
| -!- Irssi: #openrisc: Total of 39 nicks [0 ops, 0 halfops, 0 voices, 39 normal] | 21:46 | |
| -!- Irssi: Join to #openrisc was synced in 24 secs | 21:46 | |
| -!- Netsplit *.net <-> *.split quits: sb0, rah, funfunctor | 22:18 | |
| -!- Netsplit *.net <-> *.split quits: rokka_ | 22:25 | |
| -!- Netsplit *.net <-> *.split quits: mboehnert | 22:30 | |
| -!- Netsplit *.net <-> *.split quits: simoncoo1, mboehner1, arokux, jeremypbennett | 22:32 | |
| -!- Netsplit *.net <-> *.split quits: ams, trevorman, rah_, jeremy_bennett, knz | 22:38 | |
| poke53281 | olofk: I know if I will come to orconf next week. | 22:57 |
| --- Log closed Sat Sep 13 00:00:50 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!