Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns a
pointer to a dispatch function. If you request an unknown function, it
will dynamically generate a dispatch for it. Try calling
'glXGetProcAddressARB((const
Speaking of Xorg, has anyone tried the DRI DDX with Xorg? I'm trying
to get mergedfb going on xorg. I dumped the radeon DDX from the DRI
tree into the Xorg tree and rebuilt it, but the the xserver dies with a
sig 11 just after 2d accel is initialized. I haven't had time to debug
it yet.
Alex
If you build the same *_dri.so for solo and DRI, what happens to
Mesa/src/mesa/drivers/dri/radeon/*/server/*_dri.c ? As I understand it,
they're only used by solo, and derived from and different to the
corresponding files in dri.
I'm asking because if you get solo to use *_dri.c from dri, we
i810context.c
In file included from i810context.c:53:
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
parse error before XF86DRIClipRectRec
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
warning: no semicolon at end of struct
or union
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Why do you dynamically generate a dispatch for unknown functions instead of
just
returning null? What does this dispatch dispatch to?
The linux OpenGL ABI requires that GetProcAddressARB return the same value in
all contexts, including ones
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns a
pointer to a dispatch function. If you request an unknown function, it
will dynamically generate a dispatch for it. Try calling
'glXGetProcAddressARB((const
--- Robert Voigt [EMAIL PROTECTED] wrote:
If you build the same *_dri.so for solo and DRI, what happens to
Mesa/src/mesa/drivers/dri/radeon/*/server/*_dri.c ? As I understand it,
they're only used by solo, and derived from and different to the
corresponding files in dri.
I'm asking
Roland Scheidegger wrote:
i810context.c
In file included from i810context.c:53:
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
parse error before XF86DRIClipRectRec
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
warning: no semicolon at end
Allen Akin wrote:
On Thu, May 27, 2004 at 05:55:29PM -0700, Jon Smirl wrote:
| ... What does this dispatch dispatch to?
In most implementations, a dynamically-generated stub that jumps through
a known offset in a vector of function pointers. That entry in the
vector might not
On Friday 28 May 2004 10:25, Ian Romanick wrote:
Roland Scheidegger wrote:
i810context.c
In file included from i810context.c:53:
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
parse error before XF86DRIClipRectRec
So, when I updated radeon_maos_arrays.c and compiled that (btw really
brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in
radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that
codepath was only enabled in april 2002 for 9 days and probably caused a
15% slowdown
Adam Jackson wrote:
On Friday 28 May 2004 10:25, Ian Romanick wrote:
Roland Scheidegger wrote:
i810context.c
In file included from i810context.c:53:
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
parse error before XF86DRIClipRectRec
So, for whatever reason, size_t is used in drm.h in several structures
that are shared between user and kernel. HOWEVER, xf86drm.h uses int in
those places. Is it safe to assume sizeof(int) == sizeof(size_t)? If
it is, then I'm going to change drm.h to use int for now. We *really*
need a
There now exist DRI and Mesa components in freedesktop.org's Bugzilla.
I filled in some components, but I probably missed a few. DRI bugs have
dri-devel@ as the initial owner; if you change ownership of a bug it's
probably a good idea to add the list to the CC field. If anyone wants to be
Ian Romanick wrote:
So, for whatever reason, size_t is used in drm.h in several structures
that are shared between user and kernel. HOWEVER, xf86drm.h uses int
in those places. Is it safe to assume sizeof(int) == sizeof(size_t)?
Well, on ia64, sizeof(size_t)==8, while sizeof(int)==4
Stephane
On Fri, May 28, 2004 at 10:12:38PM +0200, Stephane Marchesin wrote:
Ian Romanick wrote:
So, for whatever reason, size_t is used in drm.h in several structures
that are shared between user and kernel. HOWEVER, xf86drm.h uses int
in those places. Is it safe to assume sizeof(int) ==
Maurice van der Pot wrote:
On Fri, May 28, 2004 at 10:12:38PM +0200, Stephane Marchesin wrote:
Ian Romanick wrote:
So, for whatever reason, size_t is used in drm.h in several structures
that are shared between user and kernel. HOWEVER, xf86drm.h uses int
in those places. Is it safe to assume
Ian Romanick wrote:
So, for whatever reason, size_t is used in drm.h in several structures
that are shared between user and kernel. HOWEVER, xf86drm.h uses int in
those places. Is it safe to assume sizeof(int) == sizeof(size_t)? If
it is, then I'm going to change drm.h to use int for now.
Ian Romanick wrote:
#if sizeof(sizeof(char)) == sizeof(unsigned int)
# define DRM_SIZE_T unsigned int
#elif sizeof(sizeof(char)) == sizeof(unsigned long)
# define DRM_SIZE_T unsigned long
#else
# error EVIL
#endif
Ignore that. I don't know why I was thinking sizeof() was available in
the
On Fri, 2004-05-28 at 19:22 +0200, Roland Scheidegger wrote:
So, when I updated radeon_maos_arrays.c and compiled that (btw really
brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in
radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that
codepath was only enabled
On Thu, 2004-05-27 at 11:08 -0700, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
The data was shifted to the right, making it offcenter. I will need
to
find a way of undoing/compinsating-for this inorder to make
On Friday 28 May 2004 19:49, Michel Dnzer wrote:
On Thu, 2004-05-27 at 11:08 -0700, Mike Mestnik wrote:
I try to keep each paragraph on topic, however this thread all started
with MergedFB. So I see where you could have gotten confused. What
should we call the 3dOutputClipRects?
How
22 matches
Mail list logo
