[announce] c64_tools (DSP loader and IPC)

[notaz]

This is an ASM game I believe http://boards.openpandora.org/index.php/topic/12950-tetet-falling-block-game-wasm-src/?hl=assembly

Oh nice, so he didn't disappear after all!

 

[bsp]

hmm. no comment on the new release ? (last post on previous page). it addresses your feature requests.. (among other things)

 

[rohezal]

+ add redirects for DSP-side puts/printf/vprintf/ calls (trigger linker errors)


   (--> please use syscalls.puts(), syscalls.printf(), .. instead)

Did you do this with #define printf error ?

 

[bsp]

almost (one of notaz' requests). I used


#define puts please_use_syscalls_puts
#define printf please_use_syscalls_printf
#define vprintf please_use_syscalls_vprintf
so it will trigger a linker error if you just call e.g. "printf"

you are free to #undef these things and redirect them to syscalls.*() instead, if you want to.

 

[notaz]

hmm. no comment on the new release ? (last post on previous page). it addresses your feature requests.. (among other things)

Changelog looks good, so nothing to comment about that. The .bss issue is also gone now which is nice.

I wanted to do a bit more today and then comment about it, but ended up being distracted and doing nothing useful. Read OMAP3 manual a bit, noticed that some OMAP ISP (image signal processor?) blocks can operate from memory to memory, which could be used for something interesting, maybe.

 

[bsp]

ok, thanks for the comment. glad you appreciate it. maybe I am a bit on the edge -- this all turned out so much more work than I initially hoped it would be and I've been neglecting my usual life for the past month or so just to make this happen (235h work as of now). It's about time that finally something meaningful / useful evolves from this. I am a bit tired of all this foundation kind of work, if you know what I mean.

However, I think we are close to finally conclude this chapter and move on to "the fun part"

 

[rohezal]

Your work is very appreciated . thinking long time about an efficient shortest path (fast marching) algo, which works without recursion. found one iterrative but it was strange (or better said complicated). i think your work is very useful

 

[crow_riot]

@bsp: as rohezal said, your work is greatly appreciated! Never was interested in DSP programming before, but now with your tools and library i'm keen on working with it and maybe create something useful

 

[Magic Sam]

@ bsp, notaz, and all other devs involved: thank you very much for your hard work, it's really appreciated

 

[notaz]

ok, thanks for the comment. glad you appreciate it. maybe I am a bit on the edge -- this all turned out so much more work than I initially hoped it would be and I've been neglecting my usual life for the past month or so just to make this happen (235h work as of now). It's about time that finally something meaningful / useful evolves from this. I am a bit tired of all this foundation kind of work, if you know what I mean.

Well from your things-to-do-before-inclusion plan you gave a few pages back only eDMA3 is missing, but I don't think it's really necessary to have that for first release. I think you can almost rename your *_snapshot.tar.gz to _dist.tar.gz and it can be released, my go64.sh hacks seem to be good enough.
What needs to be done though is to sort out libc64.so versioning issue. Without that programs compiled using your tar.gz (and included tests) won't run on pandora because they're linked against libc64.so instead or libc64.so.1 that OS build system produces. Something like that should work:

Spoiler

diff -ur c64_tools_/libc64/makefile.linux c64_tools/libc64/makefile.linux
--- c64_tools_/libc64/makefile.linux    2013-10-23 14:34:13.372090259 +0300
+++ c64_tools/libc64/makefile.linux     2013-10-23 14:42:32.308108648 +0300
@@ -1,10 +1,10 @@
 TARGET_BASENAME=libc64
 
-TARGET_SHARED=$(TARGET_BASENAME).so
-TARGET_STATIC=$(TARGET_BASENAME).a
-
 TARGET_SHARED_VERSION=1
 
+TARGET_SHARED=$(TARGET_BASENAME).so.$(TARGET_SHARED_VERSION)
+TARGET_STATIC=$(TARGET_BASENAME).a
+
 CC=$(CROSS_COMPILE)gcc
 RM=rm -f
 
@@ -47,20 +47,19 @@
 ALL_OBJ= $(OBJ) $(COFF_OBJ) $(ARCH_OBJ) $(OSAL_OBJ) 
 
 
-bin_shared: $(ALL_OBJ)
+$(TARGET_SHARED): $(ALL_OBJ)
        $(CC) -shared -o "$(TARGET_SHARED)" -Wl,-soname,$(TARGET_SHARED) $(LDFLAGS) $(ALL_OBJ) $(EXTRALIBS)
-       mv $(TARGET_SHARED) $(TARGET_SHARED).$(TARGET_SHARED_VERSION)
-       ln -s $(TARGET_SHARED).$(TARGET_SHARED_VERSION) $(TARGET_SHARED)
+       ln -s $(TARGET_SHARED) $(TARGET_BASENAME).so
 
-bin_static: $(ALL_OBJ)
+$(TARGET_STATIC): $(ALL_OBJ)
        $(RM) $(TARGET_STATIC)
        $(AR) r $(TARGET_STATIC) $(ALL_OBJ)
 
-bin: bin_shared bin_static
+bin: $(TARGET_SHARED) $(TARGET_STATIC)
 
 .c.o:
        $(CC) $(CFLAGS) $(CFGFLAGS) -c $< -o $@ 
 
 clean:
-       $(RM) $(ALL_OBJ) $(TARGET_SHARED) $(TARGET_SHARED).$(TARGET_SHARED_VERSION) $(TARGET_STATIC)
+       $(RM) $(ALL_OBJ) $(TARGET_SHARED) $(TARGET_SHARED) $(TARGET_STATIC) $(TARGET_BASENAME).so

 

# readelf -d c64_load
Dynamic section at offset 0x1ca4 contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc64.so.1]
...

 

[bsp]

@milkshake, crow_riot, rohezal, Shenmue, PokeParadox: thanks.. I guess that's what they call a "bad hair day", I guess..


 

Well from your things-to-do-before-inclusion plan you gave a few pages back only eDMA3 is missing, but I don't think it's really necessary to have that for first release

It's definitely necessary since it is crucial for getting good performance (it's already working here, btw).

What I do not quite understand is why you are trying to rush things with the firmware update all of a sudden.

A few pages back you said:

There are not many plans for the next fw, ED wanted to tune some scripts (when he can find time) and I still need to tune build so that "correct" SGX driver comes with 1GHz by default. So next release kind of belongs to c64_tools.

So why the hurry now ?

There is not a single DSP/c64_tools application out there that would justify an immediate FW roll out, and devs can already use it with SZ1.55.

I'd suggest to wait until at least a couple of tech demos are available (besides shell stuff that normal users probably won't look at, anyway).

These tech demos will hopefully reveal any remaining issues.

As far as I know, there's no "testing" branch of the FW, there's just the one and only "stable" branch, which gets updated every couple of months / half a year (please correct me if I'm wrong, remember I'm rather new to the Pandora (~1.5 months))

If that is true, it would be quite bad to release a new firmware now only to discover shortly after that there's still a critical bug left in c64_tools, or an API change is needed for whatever reason (as for critical bugs I just discovered one of those a short while back (data section issue) and fixed it just yesterday. I found + fixed another rather critical bug regarding multiprocess fastcalls just an hour ago).

Maybe I understood wrong and by firmware update you do not mean SZ1.56 but rather an incremental update for the current one ?

In that case aforementioned concerns would not really matter since you could quickly release a new (incremental) update in case there should be any issue.

This thread http://boards.openpandora.org/index.php/topic/12202-superzaxxon-incremental-update-changelog/ mentions that those updates "will get you development versions of various packages that are not fully tested yet".

Sounds like a good fit to me (?!).

 

[notaz]

Yes I only want it for that incremental update thing, not the "final" update. When we have that users will no longer have to install custom kernel and run shell scripts, they can just run "update pandora OS" from the menu, reboot, and then run DSP demo .pnds like all the others (we'll need some demos packaged as .pnd files though, I'm working on one of my own, slowly).

From your last posts it felt like you were tired from working on this and want to get some results, that would be the way to do it (i.e. everyone being able to run the demos easily). I don't have any reason to rush "final" SZ 1.56, ED has not even finished with his planned script updates yet.

 

[bsp]

Yes I only want it for that incremental update thing, not the "final" update.

ok that sounds reasonable. I just was not sure how these things are handled.

I have given the versioned libc64 thing another try. It works. Beats me why I occasionaly got the pthread_yield() linker errors last time I tried. The makefile is practically the same as last time *shrug*

From your last posts it felt like you were tired from working on this and want to get some results, that would be the way to do it (i.e. everyone being able to run the demos easily)

Don't worry, I am not getting tired of this in the sense that I call it quits and run away.

By results I did not mean running the existing demos but rather write some real world code, like e.g. a synth or a sprite engine (started one, called it "dsprite").

I have done some experiments with EDMA3 this evening.

Basically it is working but something wrong with the performance:

RAM<->RAM transfers are fine speedwise but e.g. L1DSRAM->RAM transfers (which should be blazing fast) do not work correctly:

• when the DMA accesses the SRAM through the L3 interconnect it is dog slow (that was to be expected), but it works (sprites are written to the FB)
• when the DMA accesses the SRAM through the local interconnect with upper 8 bits of addr. set to 0x11, the speed is about the same as with RAM but only zeros are written to the framebuffer (sprite test). I also see some DMA inband-errors in the klog. The speed scales with the sprite size, though
  
  
• when the DMA accesses the SRAM through the local interconnect with upper 8 bits of addr. set to 0x00 (DSP local), the speed is good (~1.3 GB/sec (800x480 sprites), ~675 MB/sec (1500 32bit 32x32 sprites @110 fps)), no inband-errors in the klog but still only zeroes are written to the FB
• when the DMA accesses the SRAM through the local interconnect with upper 8 bits of addr. set to 0x10 (DSP local), the speed is good (~1.3 GB/sec (800x480 sprites), ~675 MB/sec (1500 32bit 32x32 sprites @~115 fps))
  
  
  (the previous attempts did not work since I simply used the wrong L1DSRAM base address on the DSP-side, d'oh !!! thanks Notaz, the two-man rule was once again proven right!)
  

I cannot wrap my head around this. The TRM clearly states that RAM<->SRAM transfers are supported (common TI DSP programming practice) and it makes no sense to use the L3 address for the SRAM since the EDMA3 is part of the DSP module.

Here's the update in case you and/or someone else wants to take a look / investigate:

+ change signature of dsp_virt_to_phys() API call to use void* type for _virt argument


+ change signature of dsp_phys_to_virt() API call to return void* instead of sU32


+ fix multiprocess fastcall issue: force-terminate fastcall sequence only if it was started by current client


+ fix dsp_component_load(): don't try to load overlay when fastcall sequence is active (started by another process)


+ add qdma_init() DSP syscall


+ add qdma_wait() DSP syscall


+ add qdma_copy1d() DSP syscall


+ add qdma_copy2d() DSP syscall


+ add "test_qdma" DSP example component


+ change memory model of DSP core back to 'far_aggregate' (overlays still use 'far')

   (reason: weird c64_load crashes after I added some functions. Pbly because DSP/BIOS also uses f.a.)


+ add TC_QDMA_COPY1D (22) testcase to tests/c64_tc.c


+ add TC_QDMA_COPY2D (23) testcase to tests/c64_tc.c


+ build versioned libc64.so.1

+ DSP core is now compiled with full optimizations


+ add "dsprite" DSP component (early alpha)


+ add "tests/c64_dsprite.c" testcase

+ EDIT: fixed DSP base address of L1DSRAM (muchas gracias, Sir Notaz!)


+ release http://tkscript.de/c64_tools/c64_tools-23Oct2013_snapshot.tar.gz

 

[Hồng Thất Công]

notaz & bsp: just want to tip my hat to you two

 

 

[notaz]

I remember we have had similar situations before, like SDIO communication with wifi chip not working no matter what. It turned out the SDIO clock pin (which is clearly output) had to have input enable bit set in pin mux, otherwise some loopback thing didn't work and all transfers failed. This wasn't obvious as normal SD slots didn't need it at all.

So I guess situation is similar here, probably some clock needs to be enabled or magic bit set.

• when the DMA accesses the SRAM through the local interconnect with upper 8 bits of addr. set to 0x11, the speed is about the same as with RAM but only zeros are written to the framebuffer (sprite test). I also see some DMA inband-errors in the klog. The speed scales with the sprite size, though

Upper 8 bits? Doesn't that put you inside L3 address range (11000000-ffffffff)? Or do you mean bit28?
From what I see in the manual (sections 2.4.5 and 2.4.6), L1DRAM is mapped at 00f04000 and 10f04000 on DSP address space, and eDMA only sees the 10f04000 mapping (as it mysteriously sees video accelerator stuff at lower addresses, like I mentioned before).

 

[bsp]

ich werd nicht mehr.. (sry for german)

in english: BOOYA!


- #define IVA2_L1DSRAM_BASE_DSP  (0x11f04000u)
+ #define IVA2_L1DSRAM_BASE_DSP  (0x10f04000u)

seems like I happily confused some random peripheral memory for the L1DSRAM. Oh lord..

now it's blazing fast *AND IT IS WORKING* . YAY!!

 

[rohezal]

(~1.3 GB/sec (800x480 sprites)

Was this a single sprite? Or how many sprites where rendered over an other? Was it done with a full alpha channel?

 

[bsp]

(~1.3 GB/sec (800x480 sprites)

Was this a single sprite? Or how many sprites where rendered over an other? Was it done with a full alpha channel?

~887 800x480@32bit sprites overdrawn each second. no alpha blending (yet).

(..or ~14.8 fullscreen overdraws per 60Hz frame, i.e. ~325 mpixel/sec. ~100 mpixel/sec w/ alpha blending (like I estimated a few pages back) seems feasible. we'll see..)

 

[Rockthesmurf]

..or ~14.8 fullscreen overdraws per 60Hz frame, i.e. ~325 mpixel/sec. ~100 mpixel/sec w/ alpha blending

That strikes me as being a higher number of full screen overdraws than is possible via GLES, at least on my CC unit. This is purely going on memory, I could be completely wrong, but I thought I was getting fillrate bound with GLES before at like 5 or 6 overdraws per 60Hz frame. To give some comparison, the iPhone 4, with the SGX540 GPU has a fillrate of 500 MPixels/sec, so broken down:


500,000,000 pixels per second
500,000,000 / ( 800 * 480 ) = 1,302.083 full screen fills per second
1,302.083 / 60 = 21.701 full screen fills per frame

So the Pandora would be doing 2/3rd's of the amount of fill per second compared to the iPhone4 (which has a much better GPU). I believe my Pandora has a SGX530, with 200 MPixel/sec fill (8.68 full screen fills per frame at 60Hz) this is when clocked at 200Mhz (are the CC units actually clocked lower than this, 100/100Mhz or something?). Maybe the 1Ghz Pandora has a better GPU that can fill 70% quicker? Or is there some other magic going on? Maybe I have just screwed up my maths completely somewhere.

EDIT: Just noticed you clearly stated they were non alpha overdraws.

 

[bsp]

I really do not know about GLES on the Pandora, still did not get around to trying it. I also did not find any reliable fill rate and power consumption figures about the SGX530 on the web so I really cannot do any comparisons, yet.

Today I played a bit with the "dsprite" engine, added ping pong SRAM buffering, alpha testing, premultiplied and non-premultiplied srcover blending.

Those routines are far from fully optimized, for example I store the source bitmap in SRAM, yet it gets copied into another work SRAM buffer just like it would be if it were located in RAM.

However, my measurements so far show that the maximum throughput with src/dst reads is somewhere around (32 * 32 * 1500 * 63) => 96.768 mpixel/sec (sprite_w * sprite_h * num_sprites * fps).

The cool thing about the ping pong buffers is that they hide the memory access latency:

For example, when I process the current src/dst workbuffer with an alphatest function, the framerate / mpixel throughput does not change since that function is easily faster than the memory transfer.

My current (naive) C implementations of the srcover blending functions are slower than the memory transfers, therefore the pixel throughput currently drops down to (32*32*1500*33) => ~50 mpixel/sec. A little bit of intrinsics / assembly magic could resolve that / speed it up to ~96 mpixel.

Please also consider that we are talking about a lot (1500) of small (32x32) sprites here, not just a few huge ones. I think this is quite relevant for 2D video games.

This is also with ARGB32 source and dest reads so you can double the mpixel numbers for RGB565.

The L2 SRAM on the DSP is also not used, yet. Along with the aforementioned L1DSRAM sprite src data (no copy) optimizations and L2SRAM sprite data storage (up to 256kb), the performance can certainly be improved.

Last but not least, these results are preliminary so don't get too excited, yet.

Let's just say it sounds (and looks) promising (lots of Open Pandora logos flying around)

p.s.: the alphablend performance is (currently) the same when the src data is located in RAM (just tested it)

p.p.s.: the GPP / ARM is, of course, idling around while the rendering is done so it's free for other tasks. My demo app. (c64_dsprite) uses the GPP just to calculate the next sprite positions