Reicast-emulator: Software renderer [$1325]

[anothername99]

Reicast has an early software renderer: https://github.com/reicast/reicast-emulator/blob/master/core/rend/soft/softrend.cpp

This is part one in a series of bounties to get something that the average user wants to use. Here is what you need to do for this part:

• Make a copy of the current softrend
• Make it work per-pixel instead of per 4x4 quad
• Remove xmm/simd dependecies
• Make sure it works on Windows and Linux
• No hardware acceleration should be required on the user's machine

Bountysource link: https://www.bountysource.com/issues/59467315-software-renderer-bounty

---

There is a $240 open bounty on this issue. Add to the bounty at Bountysource.

[skmp]

seems good to me. Maybe mention the the existing spfteend is not portable enough? I took the speed over portability approach in it

[anothername99]

It isn't? I only have a PC so I wouldn't know anything about it if you're talking about CPU architectures.

[skmp]

The sforend is pc only atm. I think a clean, slow impl would be a perfect
start. Also fifoci, dolphin style

On Sat, 9 Jun 2018 at 20:13, anothername99 [e-mail] wrote:

It isn't? I only have a PC so I wouldn't know anything about it if you're
talking about CPU-architectures.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/1166#issuecomment-395988777,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMoVPZTjlSUVtdTehSfD2h8iKNLmXks5t7BBOgaJpZM4UhbOs
.

>

~skmp

[skmp]

Added automated bounty source integration so you should be able to add a bounty and it’ll backlink automatically

[anothername99]

Ok, does this look good?

"Added automated bounty source integration"

Nice!

[skmp]

Sure, looks like a good start. I’ll update the ticket in a bit qhen i get
home.

On Sat, 9 Jun 2018 at 20:21, anothername99 [e-mail] wrote:

Ok, does this look good?

"Added automated bounty source integration"

Nice!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/1166#issuecomment-395989221,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMnfchmWv5Es5-GI1r0RD99KZ0qvFks5t7BIxgaJpZM4UhbOs
.

>

~skmp

[twinaphex]

I have moved my bounties from the libretro repo to the reicast upstream repo -

https://github.com/reicast/reicast-emulator/issues/1167

https://github.com/reicast/reicast-emulator/issues/1168

I increased the Shenmue 1/2 bounty from $50 to $100, and I added a new bounty and added $30 to it.

Unfortunately the Bountysource integration still does not seem to work right, so I manually linked to the URLs for now.

[skmp]

Thanks

On Sun, 10 Jun 2018 at 16:40, Twinaphex [e-mail] wrote:

I have moved my bounties from the libretro repo to the reicast upstream
repo -

1167 https://github.com/reicast/reicast-emulator/issues/1167

1168 https://github.com/reicast/reicast-emulator/issues/1168

I increased the Shenmue 1/2 bounty from $50 to $100, and I added a new
bounty and added $30 to it.

Unfortunately the Bountysource integration still does not seem to work
right, so I manually linked to the URLs for now.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/1166#issuecomment-396054276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMviB-qOtpS46YtI5IjurJU2kTnKoks5t7S_IgaJpZM4UhbOs
.

>

~skmp

[skmp]

Set a bounty goal of $2000, which seems reasonable considering how much work has to get done. @anothername99 is it fine by you if we narrow down a bit the scope of this ticket, so that it is something that can be done in 60-100 hours?

I think a reasonable first sprint would be to

• [ ] Make a copy of the current softrend
• [ ] Make it work per-pixel instead of per 4x4 quad
• [ ] Remove xmm/simd dependecies
• [ ] Make sure it works in all major platforms without any hardware acceleration (android, windows, linux, osx)

It sounds good?

(updated to add without any hardware acceleration)

[anothername99]

@skmp I'm fine with narrowing down the scope. I indend to add at least $200 later this month, but I would need a lot more time to gather $2000 on my own.

Your proposed first sprint sounds good. I would just add that it should work without any hardware acceleration.

Should I keep the Android and OS X requirement? I personally don't care about those platforms but I can keep it anyway if you want.

[skmp]

I'll do some review and figure out priorities, and will probably add some more to this bounty - though it is a bit of a low priority item vs the very hot ones (Integrating the new android code, general backend cleanups and bugfixes)

[twinaphex]

It's good to have a reference renderer yeah no matter how slow. The software renderer for Naomi in MAME is still horribly inaccurate on top of being slow, so this could probably help them out a lot as well.

[baka0815]

What framework should be used for the softrend? SDL2?

[skmp]

I guess that is platform specific? For windows I do gdi blits iirc.

On Sun, 1 Jul 2018 at 23:26, Christoph [e-mail] wrote:

What framework should be used for the softrend? SDL2?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/1166#issuecomment-401634348,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMvQu0Xf9fSe1fMdkLS6yNJzHtNrFks5uCT5rgaJpZM4UhbOs
.

>

~skmp

[twinaphex]

I think it would be best not to make the software renderer dependent on a framework. Stuff like SDL or GDI blits should only be used for blitting the final output image, that way things can be kept portable without having to pull in large dependencies.

[anothername99]

I agree with Twinaphex.

[skmp]

Yes, of course, how else would it be a software renderer? 😅

On Mon, 2 Jul 2018 at 02:35, anothername99 [e-mail] wrote:

I agree with Twinaphex.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/1166#issuecomment-401644472,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMuCX0e6YzhUvV1dF2gysPDFwvBKWks5uCWrqgaJpZM4UhbOs
.

>

~skmp

[dmiller423]

Confused, why would a completely software renderer be target dependent ?
Without using any sort of SIMD it'll be terribly slow on ARM hardware but it'd technically work...

[skmp]

@dmiller423 to have as base line. The current one is simd based, and it has some bugs that are near impossible to track, cus I took no notes while writing it.

[autun12]

Excuse me if I'm just being dumb but wouldn't it make it easier if some of the functions and other stuff be easier to work on if this was seperated out into their own files?

[skmp]

I think file organization is the least of the problems of the source code.

[rimedo]

So, why is it nobody's interested in taking on the issue? It's like the coolest side project in emu scene right now, funded or not. How about this: I'll start collecting info, hypothesizing, experimenting and writing a basic rasterizer (a new one, from scratch), albeit at a snail's pace. Then, if anyone beats me to a playable prototype, I'll leave the task to them.

I've been looking into the issue for two evenings, the plan I came up with is to start by mooching off an existing hardware renderer by capturing surfaces/indices/vertices of a particularly complex scene, then recreating it in software and evaluating it against the screenshot on a per-pixel basis, possibly starting with a high-res wireframe to get the geometry transforms right.

For now I've only succeeded in patching Redream to save scenes into a set of C struct arrays, though. Today I plan to make it save the screenshot and texture data into a PNG file using Lodepng.

I'll put a notice once I have useful code to show.

Some thoughts:

The software rasterizer's (SWR) performance will be about cache locality, early Z-rejection, multithreading and SIMD friendliness, in this exact order. This means I'll be basically replicating the PVR GPU's internals in software:

• Translating the triangles to perspective-corrected screen-space coordinates (dunno if it's necessary) and calculating their screen-space AABBs.
• Assigning triangles to one or more fixed-size tiles each (32x32/64x64, based on L1 cache/cache line size) and checking for entire-tile occluding triangles (by storing and checking extra attributes per each tile, like Z-min/Z-max).
• Rasterizing each tile separately by iterating over each triangle's AABBs using the (classic) barycentric method. Whether to shade the pixels immediately or do deferred shading at the end of each tile is up to benchmark results.

Some links I found to be of use:

• Fabian Giesen's "Optimizing Software Occlusion Culling" series;
• "Learn Computer Graphics From Scratch" series;
• Kochise's Dreamcast docs collection.

Will be happy to hear anyone's opinion. Cheers!

note: This is my second github account, I've lost the first one ("nayslayer") to a reckless OS reinstall, then had some RL issues. All promises I've made till now I fully intend to deliver on, though, ashamedly, very very late.

[p1pkin]

@rimedo it highly depends on definition of "software renderer" term. there might be as much as possible faster but not really correct approximation, or simulation how real PVR2 works. or something in the middle...
PVR2 is quite unique GPU, which consists of Tile Accelerator (TA), Image Synthesis Processor(ISP), Texture and Shading Processor(TSP).
rendering process is like: ISP basically does - "for each screen pixel {for each primitive{calculate Z(x,y); doZtest; ZtestPassed?->{remember primitiveID}}} -> output [x,y,primitiveID] list to TSP", TSP does usual texture fetch, shading and blending.
in the case of translucent polygon lists ISP will output all primitiveIDs which cover screen(X,Y) in sorted order.
in the case of "punchtrough" (alpha test) polygons - TSP may do "call back" to ISP if primitive texel was rejected by Alpha test, and TSP needs next one.

[skmp]

At the moment I'm interested to model the pixel pipeline in portable C code, using the barometric coordinates interpolation we have in the existing softrend.

Ideally full s/w TA, ISP, Strip Spaner, TSP, FPU and such will follow, but those are outside the scope of this ticket.

@denim2x has also said he wants to look into this, though we haven't managed to get in sync the past 2 weeks

[skmp]

@rimedo performance is not a huge concern for this - accuracy and simplicity are.

[denim2x]

I'm working on it

[skmp]

@denim2x would be amazing to have you over at http://chat.reicast.com. We can make sure then that whatever WIP you have is going down the right part and will be easy to integrate when the time comes :)

[skmp]

This ended up getting implemented by me. See #1817 for follow up work. Will re-allocate the budget for that one.

[skmp]

@anothername99 can you please review my submitted PRs, #1807 #1809 #1812 and approve the bounty if you think the work is covered? Thanks!

[skmp]

(also I guess @rimedo sorry for not following up last year - had IRL issues)