Welcome, Guest. Please login or register.

Author Topic: FBlit opensourced  (Read 3778 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: FBlit opensourced
« on: July 13, 2015, 10:47:01 AM »
Quote from: kamelito;792389
if you've a GFX Card and this one have a blitter isn't the P96 or CGX supposedly use that in place of the Amiga Blitter freeing the CPU for other things?


Amigablitter is still used for native bitmaps.

Quote
The advantage of Blitter is freeing the CPU if you replace Blitter functions by CPU routines then you loose that CPU. If the CPU is doing nothing that fine but if you render an image for instance in the background and using you Amiga aren't you loosing time?


Amiga blitters is slow that newer CPUs can do same operations but just faster. And they could have natve bitmaps in the fast ram saving precious chip ram.

So you get faster gfx operations and save chip ram (for the musc for example)"
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: FBlit opensourced
« Reply #1 on: July 14, 2015, 11:13:35 PM »
Quote from: Thomas Richter;792395

Even worse, the current implementation of the graphics library runs into a busy-wait to let the blitter complete, it does not perform smart things such as sending the CPU into a Wait(), where it could allow another task to take over.

The decision to use such a (IMHO stupid) design was based on the slow 68K CPU. Back then, the overall overhead of the CPU reacting on a blitter interrupt, and managing and mainting such interrupts was higher than just to run into WaitBlit(), so the design remained as stupid as it is today. Whether this estimate still holds for faster CPUs, i.e. busy-wait vs. Wait(), is unclear to me and is something that is probably worth trying. At least it could free the (much faster) CPU doing something useful instead of wainting for the blitter.


I think it makes perfect sense. Busy wait in WaitBlit() is stealing CPU cycles only from other tasks and only if the blitter is still busy. Most of time the CPU had nothing useful to do anyway.

Using interrupts would mean when the blitter is already finished when calling WaitBlit() the system has gone through relatively expensive system routines (clear signal, save task pointer somewhere for the interrupt handler, signal task when ready but the signal is maybe never used). There is also chance that task is unloaded from memory before blitting operation is finished what is perfectly legal situation.
My Amigas: A500, Mac Mini and PowerBook