[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/feed.php on line 173: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/feed.php on line 174: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
Parallella Community Supercomputing for Everyone 2018-10-25T09:12:04+00:00 https://parallella.org/forums/feed.php?f=18 2018-10-25T09:12:04+00:00 2018-10-25T09:12:04+00:00 https://parallella.org/forums/viewtopic.php?t=4267&p=20095#p20095 <![CDATA[OpenCL • Re: COPRTHR-2: Host calls from the epiphany]]>
Have you had a chance to update the code to reflect the changes?

I'm still working on the idea that the ARM cores and the epiphany cores can work together in parallel so that the results from the epiphany processing can be collated on the host cores while the epiphany cores are working on the next chunk of data. I was hoping to use host calls to kick off a process on the ARM to retrieve the data from shared memory.

If there is another way of doing this I'd be glad for some pointers.

nick

Statistics: Posted by nickoppen — Thu Oct 25, 2018 9:12 am

]]> 2017-12-15T09:58:25+00:00 2017-12-15T09:58:25+00:00 https://parallella.org/forums/viewtopic.php?t=4267&p=19916#p19916 <![CDATA[OpenCL • Re: COPRTHR-2: Host calls from the epiphany]]>
I'll keep an eye out for updates.

nick

Statistics: Posted by nickoppen — Fri Dec 15, 2017 9:58 am

]]> 2017-12-09T14:54:55+00:00 2017-12-09T14:54:55+00:00 https://parallella.org/forums/viewtopic.php?t=4267&p=19914#p19914 <![CDATA[OpenCL • Re: COPRTHR-2: Host calls from the epiphany]]> Just an update. The documentation is unclear, but the bigger issue is that when I ported to the 2016 parallella image, symbol changes for this feature were overlooked. The changes from 2015 to 2016 images included completely changing the ABI symbol naming conventions and required going through and adjusting in many places. This got overlooked. I will update when I get this resolved and my test code is able to link.
-DAR

Statistics: Posted by dar — Sat Dec 09, 2017 2:54 pm

]]> 2017-11-29T09:54:11+00:00 2017-11-29T09:54:11+00:00 https://parallella.org/forums/viewtopic.php?t=4268&p=19901#p19901 <![CDATA[OpenCL • COPRTHR-2 Mutex examples]]>
Are there any examples of coprthr_mutex_init() and related functions? I would like to experiment using mutexes rather than dma_wait() which is very inefficient.

I've had a look on github but the mutex examples are all from COPRTHR-1.6 and use calls that don't appear in the COPRTHR-2 documentation.

I've got the DMA interrupts working. I want to do a mutex lock before starting the next dma operation and then doing an mutex unlock when the previous one is finished. In the interrupt I'll also call the host to copy back the data from shared memory (as in my last post).

Any help would be much appreciated.

nick

Statistics: Posted by nickoppen — Wed Nov 29, 2017 9:54 am

]]> 2017-11-28T06:56:10+00:00 2017-11-28T06:56:10+00:00 https://parallella.org/forums/viewtopic.php?t=4267&p=19899#p19899 <![CDATA[OpenCL • Re: COPRTHR-2: Host calls from the epiphany]]>
I've updated my git repository () with the call back code in it.

nick

Statistics: Posted by nickoppen — Tue Nov 28, 2017 6:56 am

]]> 2017-11-27T19:41:42+00:00 2017-11-27T19:41:42+00:00 https://parallella.org/forums/viewtopic.php?t=4267&p=19897#p19897 <![CDATA[OpenCL • Re: COPRTHR-2: Host calls from the epiphany]]> I have implemented user-defined host calls. Let me look into this to see what is going on. I will follow up.

Statistics: Posted by dar — Mon Nov 27, 2017 7:41 pm

]]> 2017-11-26T11:29:56+00:00 2017-11-26T11:29:56+00:00 https://parallella.org/forums/viewtopic.php?t=4267&p=19894#p19894 <![CDATA[OpenCL • COPRTHR-2: Host calls from the epiphany]]> Statistics: Posted by nickoppen — Sun Nov 26, 2017 11:29 am

]]> 2017-05-24T00:46:50+00:00 2017-05-24T00:46:50+00:00 https://parallella.org/forums/viewtopic.php?t=4064&p=19081#p19081 <![CDATA[OpenCL • Re: Cores stall (or crash) on e_dma_wait]]> status command in debugger.

My guess is that the "run_state" refers to the STATUS register and "debug_state" refers to the DEBUGSTATUS register. I've not idea what "info" could refer to.

However, this does not help me much. The value 0x4000000b in the STATUS register says:

- The core is active
- All interrupts are enabled
- The WAND bit is set (which has something to do with barriers but is marked as LABS which should be regarded as "experimental")
- Bit 31 is also set for core 0 but that is reserved so I've no idea what this means.

The value of the debug_state seems to indicate that everything is fine.

So interesting but not useful.

Statistics: Posted by nickoppen — Wed May 24, 2017 12:46 am

]]> 2017-05-17T00:35:32+00:00 2017-05-17T00:35:32+00:00 https://parallella.org/forums/viewtopic.php?t=4064&p=19054#p19054 <![CDATA[OpenCL • Re: Cores stall (or crash) on e_dma_wait]]>
I've updated the repository with a DMA version and an input file (bridge5.csv) that always fails for me. The file bridge0.csv works as does gray.csv.

I've left in some host_printf calls that shed some light on what is going on. There is also a global symbol (_bebug) that points to the location of the most recently transferred data.

Thanks again for helping me with this.

nick

Statistics: Posted by nickoppen — Wed May 17, 2017 12:35 am

]]> 2017-05-16T13:31:04+00:00 2017-05-16T13:31:04+00:00 https://parallella.org/forums/viewtopic.php?t=4064&p=19052#p19052 <![CDATA[OpenCL • Re: Cores stall (or crash) on e_dma_wait]]>
Those error codes never made sense to me and it would be nice if there was some way to decode it. I'll ask dar sometime (or you could).

Statistics: Posted by jar — Tue May 16, 2017 1:31 pm

]]> 2017-05-16T10:52:00+00:00 2017-05-16T10:52:00+00:00 https://parallella.org/forums/viewtopic.php?t=4064&p=19050#p19050 <![CDATA[OpenCL • Re: Cores stall (or crash) on e_dma_wait]]>
The variable name "tailEnds" is perhaps not a good one. It is the amount of data for the core modulus the buffer size. I'll make sure that it waits before sending the results back.

Do the processor states in the debug session shed any light on what is happening? I looked through the architecture reference and there is a lot of discussion about processor states but no table that relates the mnemonic with the value.

I'm getting into dma in the belief that it can be used to shift one lot of data around while the core is processing another. If the algorithm is non-trivial or needs to be run many times (e.g. neural network training) then there is a net gain, even if the data transfer is not as quick as it could be. Am I on the right track here?

nick

Statistics: Posted by nickoppen — Tue May 16, 2017 10:52 am

]]> 2017-05-15T17:08:07+00:00 2017-05-15T17:08:07+00:00 https://parallella.org/forums/viewtopic.php?t=4064&p=19045#p19045 <![CDATA[OpenCL • Re: Cores stall (or crash) on e_dma_wait]]>
Another concept that developers don't realize is that just because the DMA engine completed (after e_dma_wait) doesn't mean your data is where you think it should be. The DMA completing just means the last bit of command to move data across the network or e-link interface has been issued. You must perform a non-trivial check that the data completed moving. If multiple cores are reading or writing to that location, then you must also introduce synchronization. In the OpenSHMEM API, the coherence checking is handled implicitly by shmem_quiet after the call to a non-blocking shmem_put*_nbi or shmem_get*_nbi operation. The e-lib library provides no mechanism for this and is left to the developer.

Also, I have experienced some DMA weirdness that I never was able to pin down. I know that isn't helpful. In general, I avoid DMA with OpenSHMEM calls since synchronous copies typically beat it with Epiphany-III. Asynchronous/non-blocking code is also more complicated code. The painstakingly optimized shmemx_memcpy routine is the fastest way to write contiguous blocks of aligned memory with Epiphany-III (but it also handles misalignment).

Statistics: Posted by jar — Mon May 15, 2017 5:08 pm

]]> 2017-05-15T12:04:51+00:00 2017-05-15T12:04:51+00:00 https://parallella.org/forums/viewtopic.php?t=4064&p=19043#p19043 <![CDATA[OpenCL • Cores stall (or crash) on e_dma_wait]]> Statistics: Posted by nickoppen — Mon May 15, 2017 12:04 pm

]]> 2017-03-26T05:45:11+00:00 2017-03-26T05:45:11+00:00 https://parallella.org/forums/viewtopic.php?t=4010&p=18807#p18807 <![CDATA[OpenCL • Re: COPRTHR-2 How much free local memory do you have?]]>
I'll give it a go with the online compiler explorer (http://gcc.parallella.org/). That'll tax my brain. It's been 30 years since I did any of that sort of stuff.

I'll give the coprcc tools a go as well. Right now I've got part one of the algorithm working and so I'll get the next bit going to at least finish the whole algorithm.

I also did some timing last night and the simple "run it all on the host" version runs 20 times quicker than the epiphany version. My next job is to see what the cores are up to. I suspect that the epiphany cores are spending most of the time in idle waiting for the incoming data. I've thought about how to improve this and packing in 4 8-bit grey scale values into one 32-bit integer seems to be better use of space. Transferring 64 bits of these packed integers seems like a better use of the bandwidth.

If anyone is interested in the code, the work in progress version is here: .

nick

Statistics: Posted by nickoppen — Sun Mar 26, 2017 5:45 am

]]> 2017-03-25T06:01:30+00:00 2017-03-25T06:01:30+00:00 https://parallella.org/forums/viewtopic.php?t=4010&p=18804#p18804 <![CDATA[OpenCL • Re: COPRTHR-2 How much free local memory do you have?]]>
You might try printing out the stack pointer. If you know exactly how your code operates, you should be able to predict how much stack space is needed by analyzing the assembly. A compiler cannot analyze the code to determine stack usage. And there's the possibility of interrupts being called in some cases.

If you're really close to being able to fit an appealing amount of data, you might look at removing some code. You can use "coprcc-info" on your binary. If you're using the -fhost trick, run "coprcc --extract" on your binary to pull out the Epiphany ELF.

Statistics: Posted by jar — Sat Mar 25, 2017 6:01 am

]]>