Page 2 of 2

Re: Compositing kills SDL/MiniGL performance on the WB scree

PostPosted: Mon Aug 28, 2017 9:38 am
by Raziel
Raziel wrote:...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...

We'll get there eventually, although that won't help users of older Radeon cards (and the Radeon M9) that genuinely have less than 256 MiB.

Hans

Not to sound harsh, but with the speed of development, the boards using this chip respectively the "older" Radeon cards will be dead and/or upgraded by then anyway.
People who know about the limitations of the M9 will have to live with them, people with older Radeon cards will have to upgrade.

We need to move on! We need to get the new stuff out and not lock development by supporting the old and obsolete!

Heck, thats why i upgraded from an XE to X1K, because i knew about the limitations and wanted to use the new stuff.

Re: Silly things kill SDL/MiniGL performance on the WB scree

PostPosted: Mon Aug 28, 2017 9:14 pm
by capehill
@all

I think I found the root cause. Still some more diagnostic to do, but as a last resort, I removed a piece of code that updates window title (some stats), and performance is back. So it is not VRAM/pager issue definitely.

I will try to limit the window title update rate to work around this issue.

Re: Compositing kills SDL/MiniGL performance on the WB scree

PostPosted: Mon Aug 28, 2017 9:54 pm
by salass00
Raziel wrote:
Raziel wrote:...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...

We'll get there eventually, although that won't help users of older Radeon cards (and the Radeon M9) that genuinely have less than 256 MiB.

Hans

Not to sound harsh, but with the speed of development, the boards using this chip respectively the "older" Radeon cards will be dead and/or upgraded by then anyway.
People who know about the limitations of the M9 will have to live with them, people with older Radeon cards will have to upgrade.

We need to move on! We need to get the new stuff out and not lock development by supporting the old and obsolete!

Heck, thats why i upgraded from an XE to X1K, because i knew about the limitations and wanted to use the new stuff.


Graphics.library being able to use all the video memory of the gfx cards and not just the part that is accessible by the CPU (as the situation is now) would be very useful for newer gfx cards too.

Re: Silly things kill SDL/MiniGL performance on the WB scree

PostPosted: Tue Aug 29, 2017 5:21 am
by Hans
@vapehill
capehill wrote:@all

I think I found the root cause. Still some more diagnostic to do, but as a last resort, I removed a piece of code that updates window title (some stats), and performance is back. So it is not VRAM/pager issue definitely.

Glad to hear you figured it out.


@Raziel & Salass0
salass00 wrote:
Raziel wrote:Not to sound harsh, but with the speed of development, the boards using this chip respectively the "older" Radeon cards will be dead and/or upgraded by then anyway.
People who know about the limitations of the M9 will have to live with them, people with older Radeon cards will have to upgrade.

We need to move on! We need to get the new stuff out and not lock development by supporting the old and obsolete!

Heck, thats why i upgraded from an XE to X1K, because i knew about the limitations and wanted to use the new stuff.


Graphics.library being able to use all the video memory of the gfx cards and not just the part that is accessible by the CPU (as the situation is now) would be very useful for newer gfx cards too.

I agree with both of you, and I've been focusing on newer hardware precisely for that reason. Rest assured that the old stuff isn't holding us back. In fact, I designed the Radeon_RM.resource so that it could use all of VRAM even though the graphics.library can't (without a major rewrite). Like I said, we'll get there.

Hans

Re: Silly things kill SDL/MiniGL performance on the WB scree

PostPosted: Wed Aug 30, 2017 7:53 pm
by capehill
I did a small window title "benchmark". On Sam440ep M9 combo setting window title is about 10x slower when compositing is enabled. 1000 changes takes 7 seconds. Without compositing it takes about 0,8 seconds.

I will paste the code here if somebody is interested.

Code: Select all
/*

Compile with:

gcc windowtitle.c -lauto

*/

#include <proto/intuition.h>
#include <time.h>
#include <stdio.h>

int main(void)
{
   struct Window *w = IIntuition->OpenWindowTags(
      NULL,
      WA_Title, "Window Title",
      WA_InnerWidth, 100,
      WA_InnerHeight, 100,
      TAG_DONE);

   if (w) {
      STRPTR title = "blab blab";
      int i;

      struct timeval start, finish;
      long long duration;

      gettimeofday(&start, NULL);

      for (i = 0; i < 1000; i++) {
         IIntuition->SetWindowTitles(w, title, title);
      }
      
      gettimeofday(&finish, NULL);

      duration = 1000000 * finish.tv_sec + finish.tv_usec;
      duration -= (1000000 * start.tv_sec + start.tv_usec);
   
      printf("Took %llu microseconds\n", duration);

      IIntuition->CloseWindow(w);
   }

   return 0;
}

Re: Silly things kill SDL/MiniGL performance on the WB scree

PostPosted: Wed Aug 30, 2017 11:11 pm
by xenic
capehill wrote:I did a small window title "benchmark". On Sam440ep M9 combo setting window title is about 10x slower when compositing is enabled. 1000 changes takes 7 seconds. Without compositing it takes about 0,8 seconds.


I compiled and tried your test code on my X5000 and the difference between conpositing and non-compositing was insignificant so the problem does appear to be hardware related.
Without compositing: Took 390390 microseconds
With compositing on: Took 405765 microseconds

Re: Silly things kill SDL/MiniGL performance on the WB scree

PostPosted: Thu Aug 31, 2017 12:09 am
by javierdlr
#gcc windowtitle.c -lauto
#a.out [COMPOSITING DISABLED]
Took 100650 microseconds
#a.out [COMPOSITING ENABLED]
Took 113135 microseconds
#cpu
Sistema: AMCC PPC460EX (MC68020/FPU emulado) (INST:NoCaché)
Caché CPU: L1=32768 bytes, L2=262144 bytes.
#

RadeonHD 6570 & RadeonHD.chip 2.22 (25.3.2017)