Monkey2 Bunnymark (github)

About Monkey 2 Forums Monkey 2 Projects Monkey2 Bunnymark (github)

This topic contains 31 replies, has 12 voices, and was last updated by  Abe _King_ 1 year, 3 months ago.

Viewing 15 posts - 16 through 30 (of 32 total)
  • Author
    Posts
  • #11479

    Abe _King_
    Participant

    Unfortunately, the random order for the draw-calls is necessary, the only workaround for this at the moment would be loading it all into one texture and drawing from separate areas off that texture. That’s why I was looking for what the support is for atlases. Thanks for the code nonetheless, always interesting to see more Monkey2 in action 🙂

    #11484

    Ethernaut
    Participant

    I wanna play too!

    I forked the original, and added a simple Atlas class so we can batch all four bunnies with a single texture, without worrying about bunny order. Also added borders and made the bunnies bounce on top, to ensure we’re seeing all bunnies at any time (and cleaned the git ignore settings a bit).

    Other changes include ditching the bunny array and using a stack instead, to avoid resizing the array all the time.

    https://github.com/DoctorWhoof/Monkey2-BunnyMark

    I get about 16000 bunnies on my MacBook Pro 2015 before the framerate starts to get unstable.

    bunnies

    #11485

    Abe _King_
    Participant

    @ethernaut
    Very nice improvements I saw! I’d be very happy if you could send a pull request! I enjoy the padding you added there too, very appealing!

    I’m going to give your repo a whirl myself before hand 🙂

    [ EDIT ]
    I can now render about 1,000 more bunnies! So instead of 3.4k it’s now about 4.2-4.3k at 61 fps :). Not as much as I would have predicted, but definitely an improvement! I compared the stack against the array and it doesn’t seem to have increased performance on my end (comparing them side by side).
    Thanks for the update nonetheless!

    #11491

    Ethernaut
    Participant

    Try the new one! 🙂
    https://github.com/DoctorWhoof/Monkey2-BunnyMark

    I added “proper” sprite batching, using Canvas.DrawPrimitives, and can now go up to 44000 on my laptop, a near 3X faster result! 😮

    If I switch the GPU to Intel Iris instead of the faster AMD Radeon R9 it’s still pretty good, around 30000. All on MacOS High Sierra. Curious to see the difference on Windows.

    Instead of calling each Bunny.Draw, I now call bunnyAtlas.DrawBatch() a single time. Each bunny still updates a render queue with bunnyAtlas.QueueSprite( x, y, frame ). Take a look!

    The only bummer is that I hit some DrawPrimitive() limit (something around 16000 primitives, I believe) and had to group the render queue into smaller groups, so the code isn’t as clean as it could be.

    44K bunnies!

    #11498

    abakobo
    Participant

    I have now:

    35.5k on a 3630QM laptop with GT635M ON, on W10 (had to force GPU manually (optimus thing))

    13.4k on a 3630QM laptop with the i7(HD4000) integrated graphics, on W10. One strange thing is that when I reach the limit it switches to 30FPS directly and stays there! and if I want to go back to 60fps I first have to go back to 8k…?

    14.3k on a 3630QM laptop with the i7(HD4000) integrated graphics, on MacOs ElCapitan. no strange FPS switching to 30FPS on this one! Mac performs better that W10 on the exact same hardware! Who would have guessed it?)

    #11505

    Mark Sibly
    Keymaster

    Yay, decided to do my own bunnymark based on ethernaut’s and found a pretty major issue in mojo!

    You’re supposed to be able to use images as atlases in mojo, and New Image( image,x,y,w,h ) is supposed to ‘grab’ a frame from an atlas.

    This works BUT currently also creates a new material for the frame instead of just sharing the same material as the atlas – so my version was initially slower than ethernaut’s by a large margin! Fixing this so that all images created from other images ‘share’ the same material gives a considerable speed up – was getting about 50K images @60hz with ethernaut’s version, now get about 180K with mine!

    Will push this change to the repos soon.

    My bunnymark (works but will be slow with current mx2):

    #11508

    scurty
    Participant

    Yeah I saw the Image.Window function but I had no idea what it did exactly. xD
    I guess it clips a section of an Image like an Atlas.
    Does is pass by value, ptr, or just out-right makes a copied section of referenced atlas?

    #11509

    Mark Sibly
    Keymaster

    Hmm, can’t find an Image.Window, do you perhaps mean Pixmap.Window?

    It might have been more consistent if I’d used Image.Window, but the idea was for New Image( image,rect…) etc. to create a ‘window’ into an atlas that shares the same ‘material’ (ie: texture) as the atlas, thus minimizing renderstate changes.

    But I messed up here, and each image created with New Image( image,rect… ) actually ended up with a new ‘material’ too, which caused a renderstate change for each DrawImage. Pretty easily fixed, although there’a a minor chance it may affect some existing code out there – will deal with that if/when it happens.

    #11510

    scurty
    Participant

    Oops yep, Pixmap. My bad. Awesome! I don’t really see how that would be an issue as long as a
    MaterialSet() .Material = bleh
    and MaterialCopy:Material()
    Functions exists at some point.

    Monkey is really fast. Way faster than (excluding optimized libs) Python and a bit faster than Java from my very limited testing in the past. Very nice work Mr Sibly. 🙂

    #11515

    Abe _King_
    Participant

    Wow this is all great news! Glad to hear it from all of you. @ethernaut I got around 30-40k, a magnificent improvement I’d say :). That’s literally 10x the power! You did a lot of great work very quickly, obviously, Monkey2 is a very productive language!

    Glad to hear about the dramatic improvement from your fix @MarkSibly, stellar news :D. I’ll definitely have to give Monkey2 a whirl after the GitHub Jam!

    #11520

    nerobot
    Participant

    This works BUT currently also creates a new material for the frame instead of just sharing the same material as the atlas – so my version was initially slower than ethernaut’s by a large margin! Fixing this so that all images created from other images ‘share’ the same material gives a considerable speed up – was getting about 50K images @60hz with ethernaut’s version, now get about 180K with mine!

    Will push this change to the repos soon.

    Super-good! 🙂

    #11533

    abakobo
    Participant

    Hi

    just had a rebuild of the latest dev branch (rebuild mx2cc + rebuildall) because I saw the commit about the atlas thing but no luck I get the same results as etheraut’s version (with drawPrimitive). 🙁 too bad. Maybe there’s still something to add to the repo before I can test the code below?

    #11582

    Ethernaut
    Participant

    I actually get the exact result on my version and on Mark’s, 44K on AMD GPU and 30K on Intel on a Mac laptop. Of course it’s better to get the same result with less code!

    By the way, for the tests to look absolutely identical, you need to change this line:

    Into this (using the ‘j’ coordinate for vertical axis to actually use all four frames, plus centered handle):

    Cheers!

    #11803

    PhatPeter
    Participant

    To improve the number of draws, don’t forget to change the coordinates of all the draws from Float’s into Int’s.

    For me this makes 6K into 25K.

    Mind you that I replace the line that draws into canvas.DrawRect and used a larger sprite size of 64×64.
    Regardless of drawing method, the scaling factor going from 6K into 25K is remarkable.

    #11805

    PhatPeter
    Participant

    I can inform that fullscreen performance in some MacOS revisions are simply TERRIBLE.
    Of course that has nothing to do with this example, it’s just a general statement.

    I’ve had Monkey1 and a semi-fresh MacOS for a long time and enjoyed it very much. I didn’t update on purpose as I knew about the risk of updating and I loved the retro feel to have a working fullscreen equally powerful as  windowed apps. Last week I had to update MacOS & Xcode to get Monkey2 a try, and things broke terribly.

    Anyways, I digress. The numbers for Monkey2 and freshest MacOS you can get are :

    – fullscreen manages 12K while – Windowed manages 25K.

    You’ll notice that things gets cut in half, there’s probably a screen-buffer in the way in the system.

Viewing 15 posts - 16 through 30 (of 32 total)

You must be logged in to reply to this topic.