the osversion tags looks suspicious. I was expecting something like 1.55, not 3.2.52.919?
I do not know, it is not specified clearly. When I started looked at PND packaging this morning I found an example PXML.xml that used the kernel version. That made sense to me so I did the same.
I've played with memory tests a bit more, and I think it's just some kind of luck that your paged memcpy test almost hits 1GB/s. It's quite easy to break it, for example disabling USE_S2 already puts it ~500MB/s or below, changing mallocs with memalign(64, ..) also has similar effects. Another test here reports only ~350MB/s, which is consistent to what you get on shared memory.
The paged test probably gets the pages scattered around in physical memory in some more lucky order so that it needs less SDRAM column/row reprogramming than when they are placed in successive order in shared memory.
I have a log of the paged->paged memcpy and memset benchmark that shows
1.4 GByte/sec. That was regardless of whether USE_S2 was defined or not. Running the memperf benchmark (
the one I sent you via PM some time ago) directly after that showed just ~366 MBytes/sec, though.
Now I constantly see ~1.0 GBytes/sec with e.g. c64_tc 12.
It is really interesting (and utterly confusing!) why the memory performance changes by +-1.1 GBytes/sec. That's quite a lot!
It would probably be worth the trouble to investigate why that is and how the 1.4 GBytes/sec can be achieved consistently! (bold text since this is really quite a remarkable difference! the blocksize was too large to fit into the L2 cache)
By the way: The DSP eDMA3 peaks at ~614.4 MBytes/sec (memcpy), although that was measured with lots of 32x32 copies. IIRC, with 800x480 blocks the performance was ~1GB/sec.
The alphatested (
i.e. with dst+src reads) ARGB32 sprites in the current release perform at 32*32*1500*76 => 116 mpixel/sec (466 MBytes/sec). That's not too bad but it should be ~153 mpixel/sec once the process loop is properly optimized.
This link doesn't look like pxml for me
If the apps don't show up in the right categories, you most likely made a typo or something. Or you choose a non standart categoryname.
Hmm the link you posted is the same one I posted before and it works fine here (!?).
In the meantime I have finally managed to persuade the repo to accept the .pnd.
The repo insists on a
<descriptions> tag with at least one
<description> child node, plus an additional
<description> element directly within
<package>.
That is strange since according to
http://pandorawiki.org/PXML_specification the descriptions node is not required.
The next problem was that after the upload, the repo complained that the pnd was not using a valid freedesktop application category. That was a bit easier to fix although it was not quite obvious that in order for PND apps to show up in the XFCE "
Multimedia" menu, the "
AudioVideo" category has to be specified in the .xml.
Since subfolders are not supported (
I initially thought that <subcategory> could be used for that), I prefixed the PND application titles with "
dsp:" -- the poor man's folder, so to speak
( the updated .xml is here: http://tkscript.de/c64_tools/PXML_new.xml )
Here's the PND repo link:
http://repo.openpandora.org/?page=detail&app=c64_tools_tests
EDIT: @M-HT: thanks, this
http://tkscript.de/c64_tools/PXML_validated.xml version of the PXML is now valid
(fixed empty <title> and removed <package>.<description>)
