Re: Synchro between accelerator and fb-based drawing
On Mon, 16 Dec 2002, Rodolphe Ortalo wrote: > once again, I think I hit the problem of synchronizing the accelerator > drawings and the drawings made directly in the framebuffer by > (unaccelerated) drawing operations. > It seems there is a provision for such synchro in ggi_visual (especially > with the fields needidleaccel and accelactive). Yes, but there's some improvements needed as well IMO. Actually you're right to be confused. I think this was, well, not necessarily "hacked up" when originally implemented, but not though entirely to its logical conclusion. > I'm looking for more information on this topic, and possibly pointers to > example code inside libggi where this is used. (How is it supposed to > operate? Is there a function that should be provided by the > accelerator-specific sub lib to allow the sync?) vis->opdisplay->idleaccel should be loaded with your target's accelerator idling funtion. When a mode is set, the target is supposed to set vis->needidleaccel if it wants the stubs renderer to provide accelerator-friendly pixel functions. When the stubs renderer is opened, it checks the field and loads the pixel routines from pixel.c if there is no need for accelerator idling (needidleaccel == 0), or from pixela.c if there is a need (needidleaccel != 0). A sublib that has the need for idling the accelerator should provide at least hline, vline, box; e.g. it should not leave solid-fill primitives to the generic renderers, because the generic libs only contain "accelerator aware" versions of the single-pixel functions. The pixela functions call PREPARE_FB(vis) before altering the framebuffer. PREPARE_FB(vis) in ggi-dl.h checks to see if accelactive is true, and if it is, then it calls LIBGGIIdleAccel(vis) (a macro) which calls vis->opdisplay->idleaccel. Note it does not check that there is actually a function pointer hooked there, so it is important that accelactive never be raised unless this pointer has been initialized. (Note for some reason the stubs target uses the non-macro function form _ggiIdleAccel. I don't know why it is this way and perhaps that is just leftovers from before the macro was defined.) Now, that's the way it's *supposed* to work. The xf86dga target code still in CVS is a good example of this. In reality, and the reason why the fbdev target is currently hacked to always load pixela functions, is that some targets *do*not*know* whether they have accelleration until they have tried to load an accelerated sublib. If for one of many reasons the sublib cannot be loaded, then the pixel functions should be reverted to non-accelerated versions. Unfortunately by the time this is known, it is too late: the generic renderer is loaded before the accelarated sublibs are tried, and once it chooses between the pixel or pixela drawops, the function pointers to the other set are lost for good. Early targets just assumed that the sublib was available based on a simplistic check. The generic renderers have to be loaded before the accelerated renderers so that the accelerated renderers can overload selected pointers. Re-loading the generic renderers a second time to get the pixela functions back would cause the generic renderer to stomp on the accelerated renderer's function pointers. IMO what needs to be done is to have renderers included in the ggiIndicateChange() callback facility, and when an accelerator is loaded, the generic renderers will be able to swap the function pointers appropriately. (BTW, This is just one of many symptoms of the dl system needing to be taken one step further than it already goes. See the "dummyfunc" hacks and such used in most extensions for another.) -- Brian
Re: ggi_gc and plane_mask
On Sun, 15 Dec 2002, Rodolphe Ortalo wrote:
> Hello,
>
> is the plane_mask entry of the ggi_gc struct really used (see
> ggi/internal/structs.h)?
> There is not "update mask" associated with this field of the struct (on
> the contrary of the foreground/background color or clip coordinates), so
> I'm wondering if I should or should not overwrite the PLNWT reg of the
> Matrox each time gcchanged is called...
I'd just not worry about that for now. It's no used as far as I know,
but could be.
> Also, what is the meaning of '_nc' in draw{h,v}line_nc? (My guess is
> 'non-clipped'?)
Right. _nc primitives expect the coordinates to be pre-validated.
--
Brian
Synchro between accelerator and fb-based drawing
Hello, once again, I think I hit the problem of synchronizing the accelerator drawings and the drawings made directly in the framebuffer by (unaccelerated) drawing operations. It seems there is a provision for such synchro in ggi_visual (especially with the fields needidleaccel and accelactive). I'm looking for more information on this topic, and possibly pointers to example code inside libggi where this is used. (How is it supposed to operate? Is there a function that should be provided by the accelerator-specific sub lib to allow the sync?) BTW, with KGI, my guess is that the simplest way to provide sync() currently is to send all the remaining DMA buffers (as empty buffers) to the kernel and wait until we come back to the (previously) current one. (Usually, there are 2 buffers, so it will not take many context switches.) Rodolphe
Re: ggi_gc and plane_mask
Hi,
On Sun, 15 Dec 2002, Rodolphe Ortalo wrote:
> Hello,
>
> is the plane_mask entry of the ggi_gc struct really used (see
> ggi/internal/structs.h)?
> There is not "update mask" associated with this field of the struct (on
> the contrary of the foreground/background color or clip coordinates), so
> I'm wondering if I should or should not overwrite the PLNWT reg of the
> Matrox each time gcchanged is called...
>
I have no idea. Maybe I should look into this to for the Radeon driver.
> Also, what is the meaning of '_nc' in draw{h,v}line_nc? (My guess is
> 'non-clipped'?)
>
Correct, "no clipping"
> Rodolphe, "today ./showaccel says 40.46"
>
>
>
Also, I wrote a little test program that you might find useful; it goes
through the basic acceleration operations and displays a benchmark result.
You can find it at:
http://www.student.math.uwaterloo.ca/~pmredmon/ggibench.c
(actually, it's not really useful but certainly fun to play with :)
Paul
ggi_gc and plane_mask
Hello,
is the plane_mask entry of the ggi_gc struct really used (see
ggi/internal/structs.h)?
There is not "update mask" associated with this field of the struct (on
the contrary of the foreground/background color or clip coordinates), so
I'm wondering if I should or should not overwrite the PLNWT reg of the
Matrox each time gcchanged is called...
Also, what is the meaning of '_nc' in draw{h,v}line_nc? (My guess is
'non-clipped'?)
Rodolphe, "today ./showaccel says 40.46"
Re: multi threaded... Details
> Neil Pilgrim <[EMAIL PROTECTED]> wrote: > > > I have tested your patch under Linux/i386 and Solaris 8/Sparc32. > > > Tomorrow evening, I can test it under MacOS X/PPC32, too. > > I've tested this and it works fine for me with Fresco, after prompting > > from bughunter^WChristoph that it might fix the current problem we have > > with the rc's. It didn't, but it didn't break anything either :) > > Good. That's two thumbs up now. Commited. Great! Tnx a lot. I just verified the patch successfully under MacOSX/PPC32. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: multi threaded... Details
On Sat, 14 Dec 2002, Andreas Beck wrote:
> I spent quite a while thinking this code through, and suppose I got it
> right. I am not quite sure about the last two ifs in each chain. I think one
> could use greater/less-or-equal in the comparisions as well, thus correctly
> handling regions that just touch the borders.
/me hangs his head
Shame on me for being a cut-and-paste monkey and not revisiting that code.
All the changes look fine to me. Thanks a bunch!
BTW, on my TODO list is a helper library that does dirty-region tracking,
but it is something I probably won't get to for a long while. There
are other targets that could use dirty region management (e.g. tile).
If this sounds like an interesting diversion for anyone they are
welcome to take it off my hands :-). It is quite a fun challenge
for those of us who enjoyed algorithms 101.
The API would be something like this:
/* Initialize a helper instance and return a handle to it. */
dirty_handle = dirtyhelper_init(max_regions, cost_per_blit, cost_per_pixel,
do_blit_function_pointer, max_budget);
max_regions:A user-definiable cap on the number of dirty-regions tracked
cost_per_blit: How many points does sending a blit command cost, not including
the cost of the pixel data payload.
cost_per_pixel: How many points should be calculated per pixel when figuring
out the cost of sending the pixel data payload.
do_blit_function_pointer: A pointer to a function that unconditionally
blits a region from the backbuffer to the front-buffer.
max_budget: A limit on the number of points the dirty region manager
is allowed to accumulate.
dirtyhelper_exit(&handle) /* Frees the instance and destroys the handle */
/* Mark a region dirty, but don't blit any regions. This means even if
it is horribly inefficient to do so, when the function returns all
the dirty data should be contained in <= max_regions rectangles. */
void dirtyhelper_dirty(handle, x, y, w, h);
/* The manager adds the allowance to it's accumulated point budget. Then,
it has the option of blitting some data to the screen in order to
more efficiently fit the new region into its rectangles. The
manager must subtract the cost of that blit from it's total bugdet,
which must remain above 0.
*/
void dirtyhelper_dirty_blit(handle, x, y, w, h, allowance);
/* These are the same, for marking a region clean, e.g. when an accelarated
solid-fill primitive overwrites dirty pixels before they were moved to the
front-buffer. */
void dirtyhelper_clean(handle, x, y, w, h);
void dirtyhelper_clean_blit(handle, x, y, w, h, allowance);
/* Just let the dirty-region manager do some internal reorganization
and blitting, without making anything new dirty or clean. */
void dirtyhelper_blit_some(handle, allowance);
/* Flush all dirty regions. */
void dirtyhelper_blit_all(handle);
/* Explicitly set the number of points the dirty-region manager has
available to spend. */
void dirtyhelper_budget(handle, budget);
Targets would have the option of using
dirtyhelper_blit_some/dirtyhelper_{clean|dirty}_blit or just
using dirtyhelper_blit_all depending on their requirements.
Network based targets might also appreciate the ability to tune the
costs at runtime to adjust for dynamic latency/bandwidth ratios.
--
Brian
P.S. It boggles my mind that any of the X targets actually work
in a threaded environment :-)
Re: multi threaded... Details
Neil Pilgrim <[EMAIL PROTECTED]> wrote: > > I have tested your patch under Linux/i386 and Solaris 8/Sparc32. > > Tomorrow evening, I can test it under MacOS X/PPC32, too. > I've tested this and it works fine for me with Fresco, after prompting > from bughunter^WChristoph that it might fix the current problem we have > with the rc's. It didn't, but it didn't break anything either :) Good. That's two thumbs up now. Commited. CU, Andy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: multi threaded... Details
Christoph Egger wrote: > On Sat, 14 Dec 2002, Andreas Beck wrote: > [...] > > I have tested these changes with my application, and it fixes the problems > > I reported. > > > > Could you please go over the code and my comments and have a look, if the > > fix is right? That stuff is pretty complex to think into, so I am not > > absolutely positive I didn't mis anything. > > > > If a few people confirm my thought, I will commit. > > I have tested your patch under Linux/i386 and Solaris 8/Sparc32. > Tomorrow evening, I can test it under MacOS X/PPC32, too. > > And your patch works fine for me, so far... > Good work! I've tested this and it works fine for me with Fresco, after prompting from bughunter^WChristoph that it might fix the current problem we have with the rc's. It didn't, but it didn't break anything either :) -- Neil
Re: multi threaded... Details: Names
On Sat, 14 Dec 2002, Filip Spacek wrote: > On Sat, 14 Dec 2002, Martin Albert wrote: > > > Sorry, if you find i'm insisting or sth. like that. I feel that i have > > unsolved problems (some more?: eg. module-versioning). > > > > Tell me to shut up or to try to do more mindreading about authors > > reasons for those choices (am i not correct with: building up GGI, > > concentrating on writing fine libs for the project with easy names, ...) > > > > I think your statement is correct and valid. > > I think libggiwmh has it all: distinction, elegance, few chars to type. > > Neither variant seems to be able to make both of us happy. > > Either i'm confused or there are unsolved issues that confuse (me). > > Decisions should be made before going further with release. Lay out a > > stable concept with v.2 giving developers a clear view of a stable GGI. > > > > Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht > > einfacher. "Keep things as simple as possible, but not simpler!" > > If you don't take sth. upon yourself, somebody else _will have to_. > > > > greetings, martin (packaging gii, splitting x and really wondering / > > worrying about module-versions. libgii-target-x or libgii0-target-x is > > the question here, together with etc/ggi, lib/ggi all along). > > > Well, I suppose my comment was directed more to authors of various > extensions about the rather cryptic names of these extensions. Currently > there is libwmh, libxmi, libbse, libgic, libgpf, libblt, libbuf, libovl > in various stages of development. Maybe I'm just slower than most but > meanings of a lot of these don't seem obvious to me. IMHO, flagging them > as ggi extension by prepending their name with ggi is certainly a step > in the right direction. libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. > As far as packaging of gii goes, if I understand the issue correctly, it > boils down to binary compatibility between libgii and its input targets. > Currently if a binary incompatile change happens, the only way to keep > both versions installed would be to do some very fancy libgii.conf cruft > in order to make each of the version of libgii load the proper set of > input targets. But given that the loading of input targets is fully > under libgii control, I think it is safe to assume that if any such > change happens, libgii will provide a mechanism for loading the > different versions of input targets. Hence I would tend to think that > libgii-target-x should be the right choice. Ack. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
