Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate multi-cog vs dedicated PPU video generation approach #20

Closed
cspang1 opened this issue Nov 8, 2017 · 7 comments
Closed

Investigate multi-cog vs dedicated PPU video generation approach #20

cspang1 opened this issue Nov 8, 2017 · 7 comments

Comments

@cspang1
Copy link
Owner

cspang1 commented Nov 8, 2017

Current driver has to render faster than it can load the next tile/color at high tile dimensions, and adding the sprite rendering feature will only exacerbate this. The benefits of spreading the rendering of each line over multiple cogs vs having a dedicated PPU with screen buffer need to be investigated.

@cspang1 cspang1 added this to the VGA Tile/Sprite Driver milestone Nov 8, 2017
@cspang1 cspang1 self-assigned this Nov 8, 2017
@cspang1 cspang1 added the feature label Nov 8, 2017
@cspang1 cspang1 added this to TODO in JCAP Kanban via automation Nov 8, 2017
@cspang1
Copy link
Owner Author

cspang1 commented Nov 10, 2017

@konimaru I'm definitely interested in discussing what you discuss in this thread if you have the time: http://forums.parallax.com/discussion/126874

@konimaru
Copy link
Collaborator

Ah, that one. I felt a bit odd replying to myself :) Anyway, what are you after?

@cspang1
Copy link
Owner Author

cspang1 commented Nov 10, 2017

Thanks! I guess first off, what's the final "verdict" you reached on fully deterministic and synced waitvid timing? I see you go through quite a few iterations of solutions, and in your final version you freeze the video hardware before changing vscl. Does that have to be done for every change of vscl (for example changing for vertical blanking lines and HSync) or just initially? What's the final stream of consciousness explanation for the issues people have classically had with achieving fully deterministic timings? Is it still fundamentally rooted in what Linus Akesson discusses here?

@konimaru
Copy link
Collaborator

Let me ponder this for a while. This is really old stuff and these days I simply use it.

@cspang1
Copy link
Owner Author

cspang1 commented Nov 10, 2017

@konimaru Haha understood, no problem! I'm working on getting the general structure of this refactor together right now, so no rush!

@cspang1
Copy link
Owner Author

cspang1 commented Nov 15, 2017

@konimaru I've managed to implement a cog sync method (based on your and Linus's legwork) that's at least as good as it needs to be. I'm not going down the rabbit hole of WHOP methodology at this stage, and likely won't in the future, as the resolutions I'm working with don't require that kind of time-shaving and code obfuscation. I'm still interested in the odd behavior exhibited by the video generation hardware.

As far as this issue goes, I've chosen to go with a multi-cog approach over one requiring a dedicated PPU. My graphics demands simply aren't high enough to warrant a PPU, and at this point I've managed to wrap my head around the multi-cog approach enough to implement it.

@cspang1 cspang1 closed this as completed Nov 15, 2017
@cspang1 cspang1 removed this from TODO in JCAP Kanban Nov 15, 2017
@cspang1
Copy link
Owner Author

cspang1 commented Jan 29, 2018

This paradigm ended up being chosen as the way forward, as "my graphics demands simply aren't high enough to warrant a PPU" turned out to be an outright lie.

@cspang1 cspang1 added this to Complete in JCAP Kanban May 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
JCAP Kanban
  
Complete
Development

No branches or pull requests

2 participants