The hunt for HV's FIFO/Push buffer...

IronPeter · Post by **IronPeter** » Sat Dec 29, 2007 7:33 am

the same dump as in FW 2.01.

Nothing 3D related.

Probably, I did not understand your words about 2d object. Can you do blit from the upper vidmem? Are your 2d subchannels working?

IronPeter · Post by **IronPeter** » Sat Dec 29, 2007 7:36 am

Here http://manwe.homelinux.org/~glaurung/ps3/20071015/ is old but working RSX analyze tool.

You need to call prepare_ramin_vram_copy function.

Peter.

monolith42 · Post by **monolith42** » Sat Dec 29, 2007 7:45 am

I've had to disable the sub channel 3, FB_BLIT breaks if i try to place anything inside sub channel 3.

---
Afaict this is the vram->vram blit subchannel..
Looks like they're preventing creation of this.

IronPeter · Post by **IronPeter** » Sat Dec 29, 2007 8:13 am

hmm... Probably you want to setup not valid or "foreign" context object.

Your fifo setup seems to be broken.

monolith42 · Post by **monolith42** » Sat Dec 29, 2007 8:38 am

I don't get a valid display signal after applying ps3fb.diff for RAMIN dump and I can't connect using SSH either so I can't try to find out what went wrong.

---
Turns out I could connect after a while, booting takes a bit longer when blit is spewing messages about failed blits.
Couldn't see anything obvious in the log.

monolith42 · Post by **monolith42** » Sat Dec 29, 2007 9:00 am

RAMIN dumper returns:

vram 264241152 fifo 9437184 ctrl 4096
mmap: /dev/ps3gpu_vram len 264241152
mmap: /dev/ps3gpu_fifo len 9437184
mmap: /dev/ps3gpu_ctrl len 4096

and then the ps3 freezes, have to kill it using HV (press powerbutton for 10 seconds)

stesmi · Post by **stesmi** » Sat Dec 29, 2007 9:13 am

monolith42 wrote: and then the ps3 freezes, have to kill it using HV (press powerbutton for 10 seconds)

Splitting hairs perhaps but you can just use the powerswitch at the back unless you want to return to GameOS of course...

monolith42 · Post by **monolith42** » Sat Dec 29, 2007 9:22 am

stesmi wrote:Splitting hairs perhaps but you can just use the powerswitch at the back unless you want to return to GameOS of course...

Not really.

Holding down powerbutton when system is off -> return to GameOS with default settings.
Holding down powerbutton when system is on -> make hypervisor kill the power to the system.

stesmi · Post by **stesmi** » Sat Dec 29, 2007 6:02 pm

monolith42 wrote:
stesmi wrote:Splitting hairs perhaps but you can just use the powerswitch at the back unless you want to return to GameOS of course...
Not really.

Holding down powerbutton when system is off -> return to GameOS with default settings.
Holding down powerbutton when system is on -> make hypervisor kill the power to the system.

That's not how my system works. If mine's locked up and I press the powerbutton and hold it it always goes back to GameOS. I've been doing some testing and research myself... I'm on 2.01 though, maybe that's the difference?

Akta77 · Post by **Akta77** » Sat Dec 29, 2007 9:09 pm

stesmi wrote:
monolith42 wrote:
stesmi wrote:Splitting hairs perhaps but you can just use the powerswitch at the back unless you want to return to GameOS of course...
Not really.

Holding down powerbutton when system is off -> return to GameOS with default settings.
Holding down powerbutton when system is on -> make hypervisor kill the power to the system.
That's not how my system works. If mine's locked up and I press the powerbutton and hold it it always goes back to GameOS. I've been doing some testing and research myself... I'm on 2.01 though, maybe that's the difference?

Nope! I am in 2.01 and pressing power while "on" just switch off (via HV). No boot settings modifications. But this is not the subject :)

@IronPeter & Glaurung : Is it possible to have easily working 2D acceleration only for 2.10? I am modifying GeeXbox to make an "easy to use" media center for noobs so non linux aware people could plainfully use their box.

Thanx in advance

monolith42 · Post by **monolith42** » Thu Jan 03, 2008 10:18 am

Had some more time to mess with this post x-mas and new years.

Managed to fix the glitches that occured when trying to use Glaurung's kernel fifo_setup stuff on a 2.6.23 kernel which gives me a working display --> working pushbuffer ready for manipulation.

When executing the ps3gpu code to read RAMIN it hangs on waiting for the gpu... looks like they did something to subchannel 3 which prevents us from blitting from RAMIN.

brand77 · Post by **brand77** » Fri Jan 04, 2008 9:43 pm

Glaurung,
I would like to try ps3rsx+xf86_video_ps3 but mandos.homelinux.org is was not accessible in the last 4 days (at least)...

Where can I find it?

tnx,
brand77

Gamester17 · Post by **Gamester17** » Tue Jan 08, 2008 7:07 am

Couple of questions from a interested non-programmer (I hope that is OK?):

Once you get 2D/3D hardware acceleration working properly in libps3rsx for Linux on the PS3, will you try to get it implemented it into the official Mesa 3D Graphics Library project or?
http://www.mesa3d.org

Is the code from VMGL (formerly Xen-GL) something that could help your development of libps3rsx to get OpenGL hardware 3D acceleration working under Linux on the PS3?, ...I have no clue myself, (again, I'm only asking as an interested non-developer).

PPS! I am personally interested in 2D/3D hardware acceleration under Linux on the PS3 because that I hope it will someday mean that XBMC (XBox Media Center) could be ported to the PS3. I believe, as do many others, that XBMC could be a big driving force of homebrew development on the PS3, just as it has been (and still is) on the first-generation Xbox game-console.
http://www.xboxmediacenter.com/wiki/ind ... ote][b]Why is OpenGL 2.0 needed for XBMC?[/b]

Currently OpenGL 2.0 is needed for:
Any deinterlacing that is not linear blending (FFmpeg can only handle linear blending in software)
Video video post-processing filtering (bicubic upscaling, etc.)
Non-power of two textures for the GUI (using NPOT saves a lot of texture memory)
Hardware accelerated YUV 2 RGB conversion (actually only GLSL is needed for this, and even some OpenGL 1.5 implementations provide GLSL as an extension. OpenGL 2.0 however guarantees the availability of GLSL).

In the future OpenGL 2.0 might also be needed for:
More video post-processing filters to improve visual quality perception (via via pixel shaders, thus shader model 3 or better is required).
Hardware Accelerated Video Decoding (using the GPU hardware to assist with video decoding, via pixel shaders)

[/quote]
Best regards / Andreas (a.k.a. Gamester17)
Project Manager of The XBMC Project

ps2devman · Post by **ps2devman** » Tue Jan 08, 2008 6:03 pm

You can :

- wait for that to happen (high level api written by somebody -the hero-)

- write it yourself

- change your code so it can plug into existing low level apis

The HUGE problem is that people that have the knowledge don't deserve to sacrifice themselves...

Low level api allows to : go to the essential, write small code that does enormous things very fast, get a lots of pleasure just by creating and testing.

High level api can be extremely boring since it usually hides hundreds of annoying specific cases at hardware level. Usually it's the work of big teams, because one person alone would dive into despair quick. Maybe only way is to collect funds and hire people (maybe source forge can help to do that). But there is a major obstacle : The silence of Sony. Many will ignore such project because they will think Sony prepares something official (whereas Sony may prepare nothing but will never say so, on purpose).

Frankly if you make the effort to give up high portability and adapt your code to low level api, and just post what missing code you need, you may obtain a quicker working result...

When you ask "Will you...", clearly, there is no organization you can talk to here, planning anything on long term. What you will find here is the slow progressive assembly of little bits made by passionate people, not interested at all, I think, in boring giant tasks!

Personally, I'm working on some low level simplified api that would exist on all platform. But no ETA.

PS: Maybe there is an intermediate solution. You can provide individual test programs sources running on PC or XB1, but with minimal amount of source. Then someone interested, can create a simulacrum of high level api but working only for your specific calls. That would be a custom disguise of the existing low level api into the high level api calls you are making. Of course try to refrain from adding highly versatile parameters. Start with fixed parameters such as size, format, etc...
(and start separate thread for this specific XBMC adventure)

Gamester17 · Post by **Gamester17** » Tue Jan 08, 2008 11:19 pm

ps2devman wrote:change your code so it can plug into existing low level apis

XBMC for Linux for uses the SDL (Simple DirectMedia Layer) framework as that high-level API, so I guess that we all have to wait until somebody ('-the hero-') adds low-level API support to the libSDL framework library and then we can start looking into porting any SDL-based software (that requires 2D/3D hardware acceleration) to PS3 Linux.

If somebody want to support an high-level API then I bet most of us hope that high-level API is SDL :)

http://en.wikipedia.org/wiki/Simple_Dir ... ][b]Simple DirectMedia Layer (SDL)[/b] is a cross-platform, multimedia, free and open-source software library written in C that creates an abstraction over various platforms' graphics, sound, and input APIs, allowing a developer to write a computer game or other multimedia application once and run it on many operating systems including Linux, Windows, Mac OS X, AmigaOS and its clone MorphOS. It manages video, events, digital audio, CD-ROM, sound, threads, shared object loading, networking and timers.[/quote]
FYI; a few open source games, gaming engines, and emulators that uses SDL:
http://en.wikipedia.org/wiki/List_of_games_using_SDL
Then there is also many multimedia applications that also uses SDL.´

PS! I will start separate thread for XBMC yet as Team-XBMC does not have time to look at the PS3 yet.
(Everyone on Team-XBMC is still concentrating on getting XBMC for Linux and Mac OS X fully workable).

ps2devman · Post by **ps2devman** » Tue Jan 08, 2008 11:49 pm

With Ps3Rsx.ko module we may already have standard X11 API acceleration for 2D. Dunno if X11 is too far behind SDL in regard of what you need SDL to do for you in XBMC... Anway I'm not video specialist.
Mplayer seems to behave very well with just Ps3Rsx.ko for that matter.

I think SDL is 2D only. If you take Doom SDL for example, it's software calculated 3D put into a rectangle array of pixels, then you let SDL display the 2D array as fast as possible. I guess it will appear, with time...

3D is really insane to encapsulate in OpenGL for example, and except for casual disguises, complete library won't happen before long... I think.

Gamester17 · Post by **Gamester17** » Wed Jan 09, 2008 12:40 am

XBMC uses OpenGL via SDL 3D so better to compare it with Doom 3 SDL or Quake 4 SDL (instead of old Doom SDL):
http://www.libsdl.org/opengl/index.php

You can compile XBMC for SDL 2D or SDL 3D today already, if you compile using SDL 2D then it does not use hardware acceleration and you will see the GUI and videos render at 1 or 2 frames-per-seconds at best. You must compile using the SDL 3D which use hardware acceleration (via SDL OpenGL).
http://xbmc.svn.sourceforge.net/viewvc/ ... ADME.linux

Compound · Post by **Compound** » Wed Jan 09, 2008 12:59 am

Gamester17 wrote:XBMC uses OpenGL via SDL 3D so better to compare it with Doom 3 SDL or Quake 4 SDL (instead of old Doom SDL):
http://www.libsdl.org/opengl/index.php

You can compile XBMC for SDL 2D or SDL 3D today already, if you compile using SDL 2D then it does not use hardware acceleration and you will see the GUI and videos render at 1 or 2 frames-per-seconds at best. You must compile using the SDL 3D which use hardware acceleration (via SDL OpenGL).
http://xbmc.svn.sourceforge.net/viewvc/ ... ADME.linux

there is currently no support for opengl though

ps2devman · Post by **ps2devman** » Wed Jan 09, 2008 7:22 pm

Oh, me bad. Didn't know SDL 3D existed and encapsulated OpenGL.
(Bleh... One more layer to add... to the giant todo list...)

jonwil · Post by **jonwil** » Wed Jan 09, 2008 10:41 pm

SDL3D isn't a layer on top of OpenGL, its a wrapper for the various os-specific parts of OpenGL such as Wgl* and similar on other platforms and for the other OS specific parts required to set up a window for OpenGL to render to.

Gamester17 · Post by **Gamester17** » Thu Jan 10, 2008 9:15 pm

jonwil wrote:SDL3D isn't a layer on top of OpenGL, its a wrapper for the various os-specific parts of OpenGL such as Wgl* and similar on other platforms and for the other OS specific parts required to set up a window for OpenGL to render to.

Exacly, that is what I meant to express.

So libps3rsx should in fact replace OpenGL as the GPU abstractions layer for SDL on PS3 Linux, just as SDL uses DirectX under Win32 operating-systems, and how SDL use Quartz on Mac OS X.

This is how the SDL architecture is explained in the wikipedia article:
http://en.wikipedia.org/wiki/Simple_Dir ... [quote]SDL has the word "layer" in its title because it is actually a wrapper around operating-system-specific functionality. The chief purpose of SDL is to provide a common framework for accessing this functionality.

Because of the way SDL is designed, a lot of the source code is split into separate modules for each operating system, in order to make calls to the underlying system. When SDL is compiled, the correct modules are selected for the target system.

On Microsoft Windows, SDL actually wraps around DirectX, which in turn wraps around the video driver. Older versions of SDL used DirectX 5, but SDL 1.2 (the current stable release) requires DirectX 7 by default. Sam Lantinga has stated that he plans to use DirectX 8 in future SDL releases.

On X11 platforms, including Linux, SDL uses Xlib to communicate with the X11 system for graphics and events.

On Mac OS X, SDL uses Quartz.[/quote]There is a good picture available here which better displays the SDL abstractions layers on different platforms:
http://en.wikipedia.org/wiki/Image:SDL_Layers.svg

Compound · Post by **Compound** » Thu Jan 10, 2008 11:06 pm

so does this mean with the current knowledge of the rsx, that it may be possible to fully map SDL 3d's functionality to these commands?

Falcon · Post by **Falcon** » Fri Jan 11, 2008 3:40 am

If you have the knowledge about rsx and OpenGL it should be possible, but this is really off-topic here. We are looking for HV's fifo and push buffer. Just start a new topic about this please.

Gamester17 · Post by **Gamester17** » Fri Jan 11, 2008 7:36 pm

ps2devman wrote:With Ps3Rsx.ko module we may already have standard X11 API acceleration for 2D. Dunno if X11 is too far behind SDL in regard of what you need SDL to do for you in XBMC... Anway I'm not video specialist.
Mplayer seems to behave very well with just Ps3Rsx.ko for that matter.

It is my understanding that video playback that is not the problem (as yes XV overlays could be used for that), the real problem is the XBMC GUI needs 3D hardware acceleration (the GUI, which is really what XBMC is, a GUI, it is the XBMC GUI that makes the people who love XBMC prefer it over any other media player/center out there, commercial and open source).

This quoting one of Team-XBMC developers ("d4rk" to be specific):

XV only helps video playback so the GUI will still be rendering in software mode making it quite slow.

Using XV instead of GL in the current XBMC Linux port would anything but a fast-track to the PS3. Moreover there will be major tradeoffs in terms of UI if overlays were used instead of a GL context. Framebuffer blitting is feasible but would perform as bad as the SDL 2D build does currently and again will result in loss of functionality until portions of the skin engine that rely on the underlying 3D API get ported to use to CPU/SPE.

All in all, IMHO, it's too early to start a port. Once libps3rsx is more mature and works on newer firmwares, then it will be interesting to take a look and give it a shot.

embrion · Post by **embrion** » Fri Jan 11, 2008 8:17 pm

Nice to see You here Gamester17 :)

From my point of view I could trade those PM III fancy GUI anims and blendings for having.
Also 2.10 firmware should not be the stopper unless Sony starts to ship PS3 with it already on board (anyone knows if they flash newer firmwares on recent shippings or still the same ver as first sold PS3s ?)
User could decide if he want newest firmware or great Media Center.

The perfect situation would be with modchips like in Xbox1 case (for ex oldr firmware for Linux/XBMC and newest firmware for everything else)

Again this is only my point of view and I know that Devs will do what They think is right :)

ochnudemus · Post by **ochnudemus** » Fri Jan 11, 2008 9:08 pm

This thread was originally for discussing HV FIFO / push buffer hunt, not some software XYZ port for PS3.

This may sound bit rude but: Please stay on topic and form new thread for PS3 XBMC discussion.

stinkymonkey · Post by **stinkymonkey** » Sat Jan 12, 2008 8:31 pm

soooo off topic..
ironpeter..any updates?

IronPeter · Post by **IronPeter** » Mon Jan 14, 2008 4:43 am

stinkymonkey, nothing interesting. I'am slowly writing some kind of techdemo.

No news about 3D access in FW 2.10

stinkymonkey · Post by **stinkymonkey** » Mon Jan 14, 2008 7:47 pm

sorry for being off topic
but i would like to say thankyou to everyone who contributes...
i'm only new to this site....but
people's dedication to the ps3 is great!!
the skill and knowledge is just amazing!!

eddd · Post by **eddd** » Wed Jan 16, 2008 4:24 am

I'd also like to express my gratitude to you geniuses working on this!

3D stuff may be ruled out with the 2.10 move but what about 2D acceleration working on something like SDLMame/Mess? Is this a realistic possibility or should I just give up hope?

Thanks again.