Re: libGL/libGLX issue...
Steffen wrote: Hello, I just had the famous teapot demo going with the PhoeniX server with the SGI-GLX extension all running under kgi-0.9. This means that the GLX integration actually worked. So basically I can now commit the sources to the KGI repository and prepare for the next snapshot release. (Which basically means that I finally can get my hands on testing the kgi-0.9 acceleration framework :-)) However, I do have a question regarding the X/GLX libraries which affects the directory layout; so I need to sort this out before: The Mesa implementation merges the OpenGL library and the GLX library into libGL.so, so that only the "-lGL -lX11 -lXext" options need to be given to the linker. Is this the right thing to do? To answer my question: according to the Linux Standard Base and OpenGL ABI specifications it is. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: LibOVL: Current Status
svgalib-target: - skeleton framework Huh ? SVGAlib can do HW-sprites ? BTW: Anyone working on the Blit extension ? Would be very useful, as it will work on every target, as blitting can always be done in SW-fallback. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED]=
Re: LibOVL: Current Status
On Mon, 26 Feb 2001, Andreas Beck wrote: svgalib-target: - skeleton framework Huh ? SVGAlib can do HW-sprites ? Ooops! I oversaw that. I just wanted to set up yet another sample target. Which target supports hw-sprites? BTW: Anyone working on the Blit extension ? Would be very useful, as it will work on every target, as blitting can always be done in SW-fallback. I will start working on libgalloc to simplify the (de)allocation of resources in libovl. Then I continue with libblit to make libbse compile and runable again. BTW: Can everyone, who has some pieces of code (even some lines are acceptable), that belongs to libgalloc, send to me, please? CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
libovl - status (update)
Hi all! Here is a status update of libovl: X-target: - hardware-cursor works (responses from mouse per default) - TODO: Allow to reference a cursor to another input-devices like keyboard/joystick etc. as well Xlib-target: - hardware-cursor works (responses from mouse per default) - TODO: Allow to reference a cursor to another input-devices like keyboard/joystick etc. as well CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: LibOVL: Current Status
On Mon, 26 Feb 2001, Brian S. Julin wrote: On Mon, 26 Feb 2001, Christoph Egger wrote: Which target supports hw-sprites? None AFAIK... I don't think anyone ever added an IOCTL to kgicon for it because the support for the console pointer (that was some pretty neat code, BTW, which used some of the VGA text font to do a smooth bitmap cursor in VGA textmode -- fun stuff) required a KGI patched kernel. And right now we don't have a functional target for the newer versions of KGI. And DirectX? Doesn't it support hw-sprites, does it? CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
LibGAlloc
On Mon, 26 Feb 2001, Brian S. Julin wrote:
BTW: Can everyone, who has some pieces of code (even some lines are
acceptable), that belongs to libgalloc, send to me, please?
Low code to text ratio, but these two archived posts are critical. Take the
second one as just a suggestion, a few people liked the idea and noone
said it was crap.
http://marc.theaimsgroup.com/?l=ggi-developm=94103638018698w=2
http://marc.theaimsgroup.com/?l=ggi-developm=94518579709657w=2
I think I sent you everything from the original proposal which
was pertinant -- there was some other code/ideas, but it was trying to
define an API where the sprites/etc were full visuals, what idea
was scrapped when we realized just how much space the overhead
would take in a 3d FPS :).
TNX.
Now I have worked out an API for libGalloc. It is attached.
Any further suggestions? Is the namespace ok?
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
/*
**
LibGalloc: extension API header file
Copyright (C) 2001 Christoph Egger [[EMAIL PROTECTED]]
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
**
*/
#ifndef _GGI_GALLOC_H
#define _GGI_GALLOC_H
#include ggi/ggi.h
__BEGIN_DECLS
/* Extension management
*/
int ggiGallocInit(void);
int ggiGallocExit(void);
int ggiGallocAttach(ggi_visual_t vis);
int ggiGallocDetach(ggi_visual_t vis);
/* Structure
*/
#ifdef HAVE_STRUCT_GALLOC
typedef struct ggiResource *ggiResource_t;
#else
typedef void *ggiResource_t;
#endif
enum Resourcetype {
/* defined by extension */
RT_SUBTYPE_MASK = 0x0fff,
RT_TYPE_MASK = 0x000ff000,
/* # of hardware "layers" */
RT_OVERLAY_MASK = 0x0ff0,
/* hardware buffers mask */
RT_BUFFER_MASK =0xf000,
/* generic drawing area in same format as the main fb */
RT_SWATCH = 0x2000,
/* Right/left eye data */
RT_STEREO = 0x3000,
/* Sprite/hw cursors */
RT_SPRITE = 0x4000,
/* video */
RT_VIDEO = 0x5000,
/* any window */
RT_WINDOW = 0x6000,
/* e.g. feature connector */
RT_PASSTHRU = 0x7000,
/* there is direct MMIO access to the feature's data */
RT_DIRECTBUFFER = 0x1000,
/* Subtypes for sprite features */
RT_SPRITE_DONTCARE =0x,
/* Hardware pointer cursor */
RT_SPRITE_POINTER = 0x0001,
/* Hardware text cursor */
RT_SPRITE_CURSOR = 0x0002,
/* True sprite (a-la C-64) */
RT_SPRITE_SPRITE = 0x0003,
/* Subtypes for video features */
RT_VIDEO_DONTCARE = 0x,
/* motion video */
RT_VIDEO_MOTION = 0x0010,
/* streaming video */
RT_VIDEO_STREAMING =0x0011,
/* Subtypes for window features */
RT_WINDOW_DONTCARE =0x,
/* YUV-Viewport */
RT_WINDOW_YUV = 0x0020,
/* Subtypes of (direct)buffer types */
RT_BUFFER_DONTCARE =0x,
/* zbuffer */
RT_BUFFER_ZBUFFER = 0x0030,
/* alpha-buffer */
RT_BUFFER_ABUFFER = 0x0031,
/* stencil-buffer */
RT_BUFFER_SBUFFER = 0x0032,
/* texture-buffer */
RT_BUFFER_TBUFFER = 0x0033,
};
enum ResourceOption {
/* Doesn't matter if system memory or VRAM is used for
* resource-type.
*/
RO_DONTCARE = 0x,
/* Force to use
Re: LibOVL: Current Status
On Mon, 26 Feb 2001, Christoph Egger wrote: And DirectX? Doesn't it support hw-sprites, does it? Maybe. Good point. I dunno cause I don't do windows :) -- Brian
Re: LibGAlloc
On Mon, 26 Feb 2001, Christoph Egger wrote:
Now I have worked out an API for libGalloc. It is attached.
Any further suggestions?
It looks good for everyday use (which is the most important
part :). The functions you have defined there now would be
called after the video mode is set and would fail if they
cannot get the feature without changing the video mode. This
is as complicated as a lot of people will want to get, so
it is perfect in that way.
I think I see what you are trying to do with the params, but
it seems to me to be a bit awkward, though:
int ggiGallocCheck(ggi_visual_t vis,
struct ResourceProperties *props,
int width, int height);
...so the width and height are read-only params, and if they
needed to be modified, the new values are put in props-width
and props-height? It's kinda strange to have just the width,
height in the function param list; usually either you have
a convenience function that breaks out all the structure values,
like so:
/*
(a la ggiCheckSimpleMode.)
The problem with doing it this way is that if you change
the struct, then you find yourself wanting to change the
function params. Good for end-user API convenience functions. */
int ggiGallocCheck(ggi_visual_t vis, Resourcetype res_type,
ResourceOption res_option, int width, int height, int depth
struct ResourceProperties *readback);
or, you keep things inside the structure like so:
/* This way if we add any members to the struct, old code
will still compile and run. Also, you get a new, modified copy
of the resource properties in out, which saves you having
to copy it yourself to keep it from getting trounced.
This design is better for Intraface, in places where
mere mortals rarely tread. LibGalloc qualifies as that,
so don't spend time trying to make the "API" userfriendly. */
int ggiGallocCheck(ggi_visual_t vis,
struct ResourceProperties *in,
struct ResourceProperties **out);
There are certain cases where feature-specific properties will
have to get down to this level even if the levels above them
have chewed on them. You can't expect GallocCheck to be able
to tell LibOVL whether it can give LibOVL a sprite that has
transparancy on a certain video card or not, if all LibOVL asks
LibGalloc is "can I have a sprite?", not "can I have a sprite with
transparency?". Libraries like LibOVL should try as best they
can to keep bloat out of Galloc, but there is no way that they
can distill the features down to a few integer values in every single
case.
Also, give the "resources" a *next member to hang a linked list on.
This will be needed later when we add functions to negotiate
multiple features and negotiate them against the video mode.
so that ends up being:
/* We could do it this way, or use unions, either way we are stuck
with keeping track of res_subopts_size so we can copy resource
properties even if we do not know/care how to examine them. */
struct ResourceProperties {
struct ResourceProperties *next;
enum Resourcetype res_type;
enum ResourceOption res_option;
enum ResourceState res_state; /* Instead of GALLOC_MODIFIED error code */
void* res_subopts;
size_t res_subopts_size;
}
I'd see three actual internal functions (_ggigalloccheck, _ggigallocset,
_ggigallocget) at the core of libGalloc, which would have to be
implemented for each target. Implementing ggiGallocCheck would
look like this, using those internal functions:
struct ModeProperties {
struct ResourceProperties res;
ggi_mode mode;
};
/* Simple single feature check against current mode */
int ggiGallocCheck(ggi_visual_t vis,
struct ResourceProperties *in,
struct ResourceProperties **out)
{
struct ModeProperties this;
if (in-next == NULL) GGI_DEBUG(
"Simple resource check called with list of multiple features");
if(in-res_type RT_TYPE_MASK == RT_FRAME) GGI_DEBUG(
"Simple resource check called on a main mode placeholder");
/* Put the current mode at the top of the desired feature list. */
ggiGalloc_Mode2RT(ggi_visual_t vis, this);
if(this-res.res_type RT_TYPE_MASK != RT_FRAME) GGI_DEBUG(
"Couldn't make resource from mode (mode not set yet?)");
this-res.next = in;
/* Insist that the features be available without calling SetMode
again, even if the main mode isn't changed. */
this-res.res_state = RS_NORESET;
return(_ggigalloccheck(vis, this, out));
}
Is the namespace ok?
Actually, the "resource" thing will probably be confused
with the ggiResourceAquire() function which is used to
grab a directbuffer away from the accelerator engine.
there is already a ggi_resource_t, which is awfully close
to ggiResource_t.
The RT_* stuff might end up clashing with "Real-Time"
support libraries at some point, but that's not too horribly
likely.
--
Brian
