Dolphin, the GameCube and Wii emulator - Forums - Testers needed for refactoring of texture decode/upload code

Pages: 1 2 3 4 5 6 7

@James: Just outta curiosity, is this the first emu project you're involved in? And have you been following/using Dolphin for long (silently) or just got to it now?

(01-15-2011, 03:24 AM)StripTheSoul Wrote: [ -> ]@James: Just outta curiosity, is this the first emu project you're involved in? And have you been following/using Dolphin for long (silently) or just got to it now?

This is my first open-source project, let alone emulator, I've been involved with. I've been doing C, C++ and game dev for years. Yeah I just picked up Dolphin maybe a few months ago. It looked cool but some things bothered me like random stuttering and inconsistent behavior so I thought I'd take a gander at the code and see what's what. Ran a sampling profiler on it and found some key areas that were bottlenecks and saw some opportunities to fix it up. In all fairness, the code is extremely well written and is a very complex project. I'm amazed it works at all given the enormous complexity.

yeah, the stuttering was/is one of the major annoyances...no one else ever seemed to guess all this could be improved so much by instruction stuff. Either way, I think I speak for all here when I say we're glad you're on it Wink

(01-15-2011, 03:38 AM)StripTheSoul Wrote: [ -> ] yeah, the stuttering was/is one of the major annoyances...no one else ever seemed to guess all this could be improved so much by instruction stuff. Either way, I think I speak for all here when I say we're glad you're on it

Cool, thanks. It's a fun project but it takes up a lot of time to do things right.
My first contribution was fixing the shader disk cache bug. That removed the random stops during gameplay.
Then I worked on texture decoders for a few weeks to optimize those and that reduced a lot of other slowdowns.

Quote:Interesting screen shot. I didn't touch any EFB work. Just texture decoders and upload. They should all be working fine. I did a play-through of MKWii just to be sure since I believe it makes use of all the texture formats.

Yes but efb copies are sometimes stored as and used as textures.

Quote:yeah, the stuttering was/is one of the major annoyances...

Not that I don't appreciate his work, but I must point out that fifo and shader cache cause a lot more stuttering than texture decoding (in general).

(01-15-2011, 02:11 AM)JamesDunne Wrote: [ -> ]
(01-14-2011, 10:52 PM)KarstenS Wrote: [ -> ]Question: Why not opening a branch directly in the project at Google Code?
Because GIT >>>> SVN. Git lets me commit locally and work offline and rearrange things and revert previous work, etc. SVN requires me to be connected if I want to commit changes. Also, much less of an issue, but nobody else seems to have any branches going on in the SVN repo so I don't wanna be "that guy" that has his own.

(01-14-2011, 04:42 PM)NaturalViolence Wrote: [ -> ]+1 For a dolphin dev taking code branches seriously. We need more people like this testing experimental code BEFORE commiting it to the svn (fifo anyone?). I'll join in when I have time on the weekends.
I'm pretty sure the other devs take their work seriously . I just knew this would be a large breaking change and I didn't want to upset anyone while I was working on it. Seemed like the logical thing to do.

Also, I'm sorta the new guy so I'd like to hold off any major fluff-ups until at least my second month "on the job." lol

Slightly related, we recently have had a discussion on IRC (you maybe should hang around more often there if you've got enough time ;P) about using branches for experimental code and/or using a different version control system:

Code:

<NeoBrain> fwiw what we possibly could need would be a more active use of branching

<NeoBrain> (yeah ector- will go crazy about that :P)

<BhaaL> you really want your git, dont you? :P

<NeoBrain> erm, svn has branches too :P

<NeoBrain> take for example my clearscreen stuff... if I done that in some branch I wouldn't have spammed the svn logs that much, and could've just committed the final version in one patch

<NeoBrain> that's not to say having a complete separate unstable branch, but just a short-lived, experimental-changes branch

<ector-> git style local branching is fine. making branches on the main server like you have to do with svn has only led to pain and confusion and abandoned crap in the tree

<NaturalVi> thank you!

<NaturalVi> someone other than me is now saying it

<NaturalVi> and a dev

<NeoBrain> err

<NeoBrain> fine, then let's switch to git xDD

<NeoBrain> :/

<NaturalVi> that's too far

* BhaaL throws a trout at NeoBrain

<ector-> instead of allowing branches in the svn we should rather switch to git, yes - problem is that then everyone has to learn git -> risk of losing people. but maybe it's worth it

<ector-> it's worth thinking about anyway

<ector-> anyone can use git right now locally for their stuff anyway before committing to svn, there's tools around to make that easy

<NeoBrain> the problem is just that gcode doesnt support git, but I really like gcode

<NeoBrain> what about hg? would that one work fine? is there a tortoisehg?

<ector-> hg isn't bad

<ector-> there is tortoisehg

<ector-> git is the current fashion though :p

<artart78> I use hg on google code, I don't use advanced features, but it works well

What the discussion boils down to is that having experimental branches would be more effective if we were using Git and/or Hg (Mercurial) but they kind of suck with svn for this purpose. However, many of the other devs don't like switching version control systems (for whatever reason). Also, Google Code doesn't support Git, which would make us have to create some GitHub project, splitting the code from the issue tracker etc...

Anyway, don't expect anything to come out from this discussion.. it's pretty much dead already anyway Tongue

(01-15-2011, 05:33 AM)NeoBrain Wrote: [ -> ]Slightly related, we recently have had a discussion on IRC (you maybe should hang around more often there if you've got enough time ;P) about using branches for experimental code and/or using a different version control system.

What the discussion boils down to is that having experimental branches would be more effective if we were using Git and/or Hg (Mercurial) but they kind of suck with svn for this purpose. However, many of the other devs don't like switching version control systems (for whatever reason). Also, Google Code doesn't support Git, which would make us have to create some GitHub project, splitting the code from the issue tracker etc...

Anyway, don't expect anything to come out from this discussion.. it's pretty much dead already anyway

Heh yeah I figured that was the case. Sorry I don't have enough time to hang out in IRC and be productive simultaneously lol. Either at work or at home working on Dolphin. Tongue

I just use git-svn like what ector was referring to. It works well enough if you don't go wild with branches and merges in your git repo, and also if you actually "get" git lol. It took me a while to get it. I agree with you re: google code. Very sexy interface which is unfortunately tied to the centralized development model. If there were other nice web tools out there tailored to a distributed model that'd be ideal.

(01-15-2011, 05:21 AM)NaturalViolence Wrote: [ -> ]Yes but efb copies are sometimes stored as and used as textures.

I believe that's irrelevant to this specific section of code I'm working on. Those copies are done at a later stage in the render and aren't related to texture decode/upload.

(01-15-2011, 05:21 AM)NaturalViolence Wrote: [ -> ]Not that I don't appreciate his work, but I must point out that fifo and shader cache cause a lot more stuttering than texture decoding (in general).

I think the shader cache is the best it's going to be for now. You only see the stutters during first-time gameplay and never again. The stutter is caused by generating the shader code and compiling it on-the-fly and flushing that to disk to be loaded next gameplay.
FIFO: I'm not by any means an expert on how this works, but it seems to me that significant performance gains here can only be accomplished by introducing higher-level emulation, like a reimplementation of the GX library that the Wii games are linked to. If we intercept execution at the function-call level here rather than emulating the implementation details of what the Wii GX library functions are compiled to do, we can gain significant performance benefits. Otherwise we're just tuning what appears to be a slow, software equivalent of a fast hardware communication mechanism. Best to just remove the bottleneck's existence than to widen the neck. This is a very large change and would take a very long time to get into some working state. Almost to the point of a project fork.

@NaturalViolence: Yeah, right, but it was also James who fixed the shader cache from dumping stuff again and again; that's when the worst stutters (at least for me) disappeared.

(01-15-2011, 05:54 AM)StripTheSoul Wrote: [ -> ]@NaturalViolence: Yeah, right, but it was also James who fixed the shader cache from dumping stuff again and again; that's when the worst stutters (at least for me) disappeared.

Yup. That was technically my first change to the project. r6690. *tear*. I'll remember that number forever Tongue

(01-15-2011, 05:43 AM)JamesDunne Wrote: [ -> ]I just use git-svn like what ector was referring to. It works well enough if you don't go wild with branches and merges in your git repo, and also if you actually "get" git lol.

Seems git-svn has a few nasty bugs. Dammitall, am I gonna have to contribute to THAT project too now?! Lol.

Quote:@NaturalViolence: Yeah, right, but it was also James who fixed the shader cache from dumping stuff again and again; that's when the worst stutters (at least for me) disappeared.

I stand corrected. I've been using 6505 due to the recent fifo changes and never noticed.

Pages: 1 2 3 4 5 6 7