OpenHandhelds.org

Count me in as a "me too" for the driver hacking .. I'd for sure like to see all possible hardware being supported with open code, but until that is possible, lets support those who will reverse engineer the beast as much as possible! Go right ahead, in my opinion: reverse engineer those binary blobs!

Surely reverse engineering the blobs directly (disassembling) is of dubious legality? Though perhaps that's not what you meant!

The way might be dubious, the end result won't.

Edit:
The discussion is fascinating but I suggest, that if things get going you should continue the discussion behind closed doors with a few capable adepts. ImgTec might be not so amused, they are very restrictive regarding their intellectual property. No one can prevent you from talking to the SGX the way you want, as long as you don't use copyrighted material in the end.

As andy_js pointed out and I quoted legal base here(link) it's perfectly legal in European Union.
So at least I'm safe.

(A rant).

I was always little dumbfound how many people seem to love (non-pure) virtual functions in C++. In most of scenarios - 1-level depth inheritance virtual functions can be replaced with templates (like here(link)). Additionally in all cases I've encountered so far usage of virtual functions was a result of bad design choices or poor understanding of their limitations.
I'm all for virtual functions in code that does not need to be fast & optimized, but code inside driver should definitely be both fast and optimized.

And analyzing disassembled file generated from such without attached debugger is a pain in the... (most painful place you an think about).

I'm ranting because almost every function inside this binary 'blob' that's loner than 100 bytes calls some virtual function. And yes - user-space module is written in C++.

So - I guess most of work will be done when my precious Pandora will arrive.

A side note: Does somebody know what's the mechanism is used to send work to HW in DRI driver ? Because when you'll prepare some compiled shaders, fill out the data structures you must eventually press 'go' button. I'm trying to find this button...

This is good point.

Does this forum has capability of private threads ?

Not so much, but you could use PMs or a (passkey locked) IRC channel.

It does. I suggest sending a PM to ED asking for a special hidden forum for this purpose. Include a link to this thread. I'm sure he'll see the importance of your work and help you out.

ooooh, just when things are getting really exciting, they go underground

well, thanks for the fascinating read so far, anyway

i suspect the 'go' button is somewhere in tungsten's TGSI code (specs).

TGSI is the shader interface part of tungsten's gallium3D universal GPU driver platform.

If a virtual method is called once or twice per frame (which it should ) it makes pretty much no difference.
Using templates has its own downsides , potential code bloat being one …

Wow, this is a major undertaking! I would help if i could, but this is definitely out of my league.

Heh - I just realized something (in greenish bold), obvious for rest of you folks, probably.

SGX uses tilled rendering. This mean that:

1. entire scene geometry is accumulated in memory
2. vertex shaders execute
3. for each image tile list (or bitmap) of triangles covering this tile is generated
4. for each tile
   
   1. triangle list is converted to bitmap each pixel being ID of triangle to shade
   2. for each pixel pixel shader associated with identified triangle is executed (everything happens in on-chip buffers)
5. results are stored in memory

The most important part is that there is a clear separation between vertex shader execution and pixel shader execution. It means that:

• During (2) only vertex shaders execute, during (4) only pixel shaders execute. This is important from HW resources perspective.
• Procedural geometry would be nice, but to reference gradients/variables in pixel pass (4) triangles must exist (=be stored in memory), because they're indexed in (3) and generated after/during (2). So if we want to generate triangles by SGX - we must store them into memory.
• Per-tile list of covering triangles has unspecified length at runtime, but if you use a bitmap - it has resolution of screen (multiplied it by anti-aliasing factor). If tiles are 16x16 for 4xAA it means 4096 bytes/tile (nice round number). This would be 5.86MB for 800x480 screen. At the same time next tile image could be pre-fetched during current tile processing in (4)... I wonder which is it (list of bitmap).
• Because in (3) new data is generated both memory reads and writes occur. Suddenly cache seems more important than before.
• Because in (4) all writes occur into on-chip buffers rather complex pixel shaders should run efficiently. As long ad they don't use a lot of textures... Procedural materials anyone ?

maciek, i don't think a simple bitmap would suffice as the final pixel ownership register - that'd do only for tiles with entirely-opaque content. the moment traslucencies step in you'd need more than one triangle id per pixel. in the general case, you need a list of triangle id's per pixel.

but you're right about the scene content binning and geometry shaders - those would need to generate actual bin content. which raises the question can you saturate your binning mechanism with a hogging geometry shader..

Yup, you are right. I forgot about transparency.


And that seems very interesting, because SGXes with more shader are claimed to be DirectX 10.1 compatible, and present very respectable throughput (see table on page 6 [and text below it] here(link)).
DirectX 10.1 compatibility means SGX 545 is geometry shader-capable. But the major benefit of geometry shaders is that geometry is created inside chip and during entire processing remains inside. This way memory bandwidth is not an issue. I don't see how would they do when binning (associating triangles with tiles they cover) enters the picture.
Unless the store everything in memory between passes and it's darn slow...

Because if they do - emulating vertex and geometry shaders in any other unit (CPU, DSP) should actually improve performance, because both tasks could be done in parallel. That would of course mean storing two consecutive frames in RAM, so it has its own disadvantages.

According to Wikipedia revisions newer than CLX2 don't have order independent translucency anymore - whether or not this impacts the triangle to pixel ratio (if it's true) I couldn't say.

Also, this is probably dead obvious, but the geometry stages (1-3) happen in parallel with the rasterization stages (4-5), meaning that there's no reason why pixel and vertex shaders shouldn't both be executing at the same time. Yes, this means that the rendering is a frame behind. Of course, nothing you said contradicts this so I'm probably just saying simplistic things...

Anyway, you guys clearly know this stuff indepth, very interesting insights.

Hi again Exophase.
I don't really think it does happen in parallel in SGX. I of course it could happen in parallel, but this would mean that rasterization stage is working on frame[n] and vertex processing goes for frame[n+1]. This would generally be great idea in architecture with lots of processing resources (because shader units would be shared between rasterization and vertex processing), large caches (because HW would be referencing data from two separate frames) and large memory buffers (because geometry of two separate frames would have been stored in RAM).
But of course, it's possible.

sorting or not, you have multiple triangles affecting a single pixel when translucencies are involved - the pixel ownership logic needs to know which those triangles are, even if they ended up drawn in an arbitrary order. and the pixel ownership test, on its turn, is needed to resolve opaque overdraw.

maciek_urbanski; What I can tell you for sure is that the PowerVR CLX2 on Dreamcast does the geometry binning stage in parallel with the tile based rasterization stage. This actually has a few nice implications for emulating Dreamcast, in that both processes are basically atomic for an entire frame, and so can be parallelized. I don't see any ways in which moving vertex shading onto the GPU and adding pixel shading would get in the way of this, but if you see something let me know...

I think you are suggesting that if they were not done in parallel then the memory for the backbuffer and for the tile bin lists could be shared.

About the lists themselves, I don't really see how the bitmap concept works with TBDR, because then the triangle would at least have to be partially rendered to determine which pixels it occupies, and this would basically be like early a traditional renderer with early Z-test. It would have to cover the same framebuffer regions in two completely different passes, which is not cache friendly. Also note that the polygons per second limitation is due to binning, not geometry calculations (look at the GeForce 3 which claimed much higher polygon transformation based on shaders). If binning were done per-pixel then the maximum number per frame would be a function of the size of the polygons, not the number of vertexes. So I really believe that the binning does result in lists of what triangles are in which tiles (per tile), and not per-pixel per-tile. Yes, this list can grow up to the number of vertexes, but there are any number of ways of dealing with growing size lists (and compromises between those and fixed size ones). Not that I can say exactly what algorithm and data structures the binning uses, but in real scenes triangles will tend to be relatively well distributed. It might be N triangles per chunk and linked list of chunks from a global pool of them.

rendered, as in 'ended up in a framebuffer' - no, scan-converted - yes. only for the span of the tile, though.


the number of vertices also affects the number of triangles per scene. also, per-tile binning is a function of the size of the triangles, as their size directly contributes to the numbers of triangles in the bins. nothing differes in this regard from per-pixel binning (aside from the scale) - even the maximal bin size would be the same.

anyway, regardless of any binning policies, a TBDR needs to arbitrate pixel ownership within its working tile - whether it's done through per-pixel binning, or through other means, a scan-conversion is inevitable.