-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Roberts wrote:
Michael wrote:
I don't see why they should be enabled - they're PC-specific and even
with x86 emulation they would be pretty much useless since you're not
too likely to encounter a graphics board with PC firmware in a Mac ( or
Torrey Lyons wrote:
At 3:42 PM -0400 4/13/05, David Dawes wrote:
On Wed, Apr 13, 2005 at 11:52:47AM -0700, Torrey Lyons wrote:
Bugzilla #1576 and the fix committed for it is only partially right.
The patch applewmExt.h is right, but patching the imported Mesa code
in
Dr Andrew C Aitchison wrote:
On Tue, 8 Feb 2005, David Dawes wrote:
It looks like the DRM kernel source in xc/extras/drm is broken and
incomplete, especially for BSD platforms. The Linux version only
appears to build for a narrow range of kernels, and this either
needs to be fixed, or the minimum
Bussoletti, John E wrote:
At Boeing we have a number of graphics applications that have been
developed in-house, originally for various SGI platforms. These
applications are used for engineering visualization They work well on
the native hardware and even display well across the network using
F. Heitkamp wrote:
I can't get agp to work with my Apple G4. When I enable DRI X comes up
but the resolution appears to be 640x480 and the mouse cursor is large,
distorted and quivering. No user input is possible at this point.
Is AGP support for the G4 still under development or is it
[EMAIL PROTECTED] wrote:
Following to the post http://www.mail-archive.com/[EMAIL PROTECTED]/msg16132.html
I think I have found where the problem is : line 1024 of mkfontscale.c while calling
FT_Get_Name_Index.
n parameters value is space when it crashed. I didn't checked all values of data in
Kevin E Martin wrote:
I think many of us would very much like to have hardware accelerated
indirect rendering, and from time to time there has been talk of adding
it to the DRI project. It's actually been on the to do list for the
DRI project from the original design days, but it's a large
Ryan Underwood wrote:
Not a common scenario. I know a lot of G550's come with a DVI and an
analog connector, but I've never seen a G450 like that. (The G450
manual claims that they exist., however.)
I have a PCI G450 (for PowerPC, no less) that has this configuration.
Of course, I can't get it
Marc Aurele La France wrote:
Well, domain support for MIPS has yet to be written. Ditto for PowerPC. And
that for Alpha's is somewhat broken. Lack of time, for one, and lack of
hardware.
Is there some guidance or documenation for how to do this? I'm about to
be forced (heh...) to write domain
Mark Vojkovich wrote:
On Tue, 2 Mar 2004, Sottek, Matthew J wrote:
It's currently global because the hardware I work on doesn't
have to fall back to software very often. Bookkeeping on a per-
surface basis is a simple modification and one I will add. This
precludes using XAA2 with hardware
Mark Vojkovich wrote:
Ummm... which other models are you refering to? I'm told that
Windows does it globally. Having per-surface syncing may mean
you end up syncing more often. Eg. Render with HW to one surface
then to another, then if you render to SW to both of those surfaces,
two syncs
Sven Luther wrote:
I think that ATI is missing something here. I believe that Powerpc
hardware with ATI graphics represent a ever growing linux installed
base, with the G5 Powermac, with the new powerbooks, as well as with
non-apple powerpc boxes like the pegasos motherboards. But then, it is
Sven Luther wrote:
On Fri, Feb 20, 2004 at 07:55:27AM -0800, Ian Romanick wrote:
Sven Luther wrote:
I think that ATI is missing something here. I believe that Powerpc
hardware with ATI graphics represent a ever growing linux installed
base, with the G5 Powermac, with the new powerbooks
jaspal kallar wrote:
I know there is already 2D support for the radeon 9600 pro in the upcoming 4.4 release.
My question is if I buy an Apple Powermac G5 with a radeon 9600 pro card will I eventually in the future be able to
get 3D support on the powerpc platform (not x86!!) ?
Only if ATI ports
I'm making some changes to the server-side GLX in the DRI tree. For
part of my changes I want to eliminate the need for libGLcore to have
access to a VisualRec (programs/Xserver/include/scrnintstr.h, line 68).
There are only two fields from that structure that are accessed by
libGLcore, and
Keith Packard wrote:
Around 9 o'clock on Feb 17, Ian Romanick wrote:
First, a comment in the structure says that nplanes is log2
(ColormapEntries). Does that mean that (1U v-nplanes) ==
v-ColormapEntries is always true?
no. ColormapEntries on a Direct/True visual is
1 max(nred,ngreen
Torrey Lyons wrote:
These fixes have the side effect of breaking GLX on Mac OS X. The
problem is the addition of new server side dependencies on
glPointParameteri, glPointParameteriv, glSampleMaskSGIS,
glSamplePatternSGIS. Mac OS X instead uses glPointParameteriNV and
glPointParameterivNV and
Andreas Stenglein wrote:
Am 2004.02.04 21:00:14 +0100 schrieb(en) Brian Paul:
Ian Romanick wrote:
Making that change and changing the server-side to not advertise a core
version that it can't take protocol for would fix the bug for 4.4.0. Do
you think anything should be done to preserve text
Michel Dnzer wrote:
On Wed, 2004-02-04 at 00:56, Ian Romanick wrote:
Does anyone know if either the ATI or Nvidia closed-source drivers
support ARB_texture_compression for indirect rendering? If one of them
does, that would give us a test bed for the client-side protocol
support. When
Brian Paul wrote:
Ian Romanick wrote:
That's *bad*. It is currently *impossible* to have GL 1.5 with
indirect rendering because some of the GLX protocol (for
ARB_occlusion_query ARB_vertex_buffer_objects) was never completely
defined. Looking back at it, we can't even advertise 1.3 or 1.4
Mike A. Harris wrote:
On Sat, 31 Jan 2004, Ryan Underwood wrote:
where is the docs for the VSA based cards (voodoo4/voodoo5)? I have
been unable to locate them.
In a chest in a basement at Nvidia somewhere, with a lock on it,
behind a bunch of old filing cabinets, in a room at the end of a
Andreas Stenglein wrote:
after setting LIBGL_ALWAYS_INDIRECT=1
glxinfo shows
OpenGL version string: 1.5 Mesa 6.0
but doesnt show all extensions necessary for OpenGL 1.5
An application only checking for GL_VERSION 1.5 would probably fail.
Any idea what would happen with libGL.so / libGLcore.a
Ryan Underwood wrote:
Your request for free publication is undeniably idealistic. I think it
is a perfectly reasonable compromise to provide specs under NDA to
developers who have shown themselves to be productive and trustworthy in
the past, e.g. by contributing to XFree86 or producing and
David Dawes wrote:
What is the correct typedef for PFNGLXGETUSTPROC? glxclient.h has:
typedef int (* PFNGLXGETUSTPROC) ( int64_t * ust );
and it is used as a signed quantity in glxcmds.c.
But most drivers use uint64_t, and src/glx/mini/dri_util.h in the Mesa
trunk uses unsigned:
typedef int
Torrey Lyons wrote:
In building the top of the tree on Mac OS X 10.2 I have run into
troubles linking the GLX support in Xserver/GL. The problem is that
native OpenGL in Mac OS X 10.2 does not include glActiveStencilFaceEXT()
and glWindowPos3fARB(), which have been added to g_render.c and
Frank Gießler wrote:
with my current CVS snapshot (Changelog up to #530), glxgears gives me
the following at startup:
X Error of failed request: BadLength (poly request too large or
internal Xlib length error)
Major opcode of failed request: 144 (GLX)
Minor opcode of failed request: 1
Vahur Sinijarv wrote:
Does anyone know if fast z-buffer clears and 'z-compression aka hyper-z'
are going to be implemented in radeon DRI drivers (actually it is in the
'radeon' kernel module). It seems to be one of the areas where major
performance gain could be achieved, taking this driver to
Mike A. Harris wrote:
If DRI is disabled, then the Radeon driver will use the older
MMIO mechanism to do 2D acceleration. I don't know what if any
of the other drivers will use DRI for 2D or Xvideo currently,
however any hardware that supports using DMA/IRQ for 2D
accelration or other stuff
John Dennis wrote:
For DRI to work correctly there are several independent pieces that all
have to be in sync.
* XFree86 server which loads drm modules (via xfree86 driver module)
* The drm kernel module
* The agpgart kernel module
Does anybody know for the proprietary drivers (supplied by ATI
Jakub Jelinek wrote:
The first is a MUST list, symbols which are exported from XFree86 shared
libraries now when there is no anonymous version script, are not exported
when an anonymous versions script created from stock *-def.cpp file
is applied and are used by some binary or shared library
Andrew P. Lentvorski, Jr. wrote:
I just grabbed the latest source from CVS and compiled. While the system
is identifying itself as 1.3 Mesa 5.0.2, glXGetFBConfigs seems to be
always returning a NULL pointer for any combination of attributes I can
feed into it.
The core OpenGL version is different
Jakub Jelinek wrote:
1) could be done by some header which everything uses, doing
#if defined HAVE_VISIBILITY_ATTRIBUTE defined __PIC__
#define hidden __attribute__((visibility (hidden)))
#else
#define hidden /**/
#endif
and write prototypes like:
void hidden
Raymond Jennings wrote:
I'd like to suggest that you implement device-specific code as a kernel
module.
This has been discussed to death. XFree86 is portable to systems where
we can't just willy-nilly add kernel modules. With few exceptions, such
as to implement hardware 3D, this is right
Keith Whitwell wrote:
I haven't deeply investigated this but two solutions spring to mind:
- Hack: Move the call to RADEONAdjustFrame() during initialization
to before the lock is grabbed.
- Better: Replace the call to RADEONAdjustFrame() during
initialization with something like:
Mark Vojkovich wrote:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usleep(0) is not good for this because it's jiffy based and usually
never returns in less than 10 msec which has the effect of making
Mark Vojkovich wrote:
On Mon, 22 Sep 2003, Ian Romanick wrote:
Mark Vojkovich wrote:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usleep(0) is not good for this because it's jiffy based and usually
never
Nathan Hand wrote:
On Tue, 2003-09-23 at 07:55, Mark Vojkovich wrote:
On Tue, 23 Sep 2003, Nathan Hand wrote:
On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
Cheshire Cat Fish wrote:
Mesa support/conformance is a requirement. The resulting SMI drivers
would remain open source, and part of the Xfree/DRI/Linux distribution.
That is the plan at least.
That's good news. :)
There are way too many variables to be able to accurately answer that
question
Cheshire Cat Fish wrote:
I am investigating supporting DRI and OpenGL for the Silicon Motion driver.
I'm new to both of those, so some of these may be newbie sounding
questions.
1) I have the OpenGL code from the Windows 2000 Silicon Motion driver.
Can this code be mostly used as is? Or
Jakub Jelinek wrote:
On Sun, Aug 10, 2003 at 07:06:58PM -0500, Warren Turkal wrote:
@@ -1003,6 +993,8 @@
break;
}
+r128_drm_page_size = getpagesize();
+
sysconf (_SC_PAGESIZE)
is the standardized way of querying page size.
I seem to recall some discussion about this a few months
Egbert Eich wrote:
There is a report in bugzilla (#439) which claims:
the bug is in xc/lib/GL/glx/glxcmds.c
int bufSize = XMaxRequestSize(dpy) * 4;
should be
int bufSize = XMaxRequestSize(dpy) * 4 - 8;
or more cleanly
int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq);
it happens
Ian Romanick wrote:
Egbert Eich wrote:
There is a report in bugzilla (#439) which claims:
the bug is in xc/lib/GL/glx/glxcmds.c int bufSize =
XMaxRequestSize(dpy) * 4;
should be int bufSize = XMaxRequestSize(dpy) * 4 - 8;
or more cleanly
int bufSize = XMaxRequestSize(dpy) * 4 - sizeof
Doug Buxton wrote:
I'm a new to the XFree86 sources, so I was hoping someone could give some suggestions as to where to start looking. Is there an existing mechanism for changing drm drivers, or restarting drm without restarting X entirely? I'm trying to find a way to make X gracefully handle
Mark Vojkovich wrote:
On Sun, 1 Jun 2003, Jon Leech wrote:
You might want to think about how this could carry over to the
upcoming super buffers extension, too, since that will probably replace
pbuffers for most purposes within a few years. Since super buffers
There are alot of people who are
Alex Deucher wrote:
Sis wrote support for the 300 series and it works. However, when mesa
4.x came out no one ever updated the sis dri stuff to match the new
structure. so DRI works with the 300 if you use the mesa 3.x libs. It
shouldn't be too hard to port the sis stuff to mesa 4.x, but there
Mark Vojkovich wrote:
On Sun, 1 Jun 2003, Jon Leech wrote:
On Mon, Jun 02, 2003 at 01:09:59AM -0400, Mark Vojkovich wrote:
Extending GL to recognize a relatively unknown XFree86 format
is a hard sell. I wouldn't even be able to convince my own company
to dirty their code for it seeing as how
Sottek, Matthew J wrote:
Let me preface my comment with I don't know a lot about OGL so some
further clarification may be needed.
I am assuming that pbuffers are basically buffers that can be used
as textures by OGL. I would then assume that the OGL driver would
have some mapping of pbuffer id to
Thomas Winischhofer wrote:
Alex Deucher wrote:
right now just the 300 series (300, 305?, 540, 630/S/ST, 730) have DRI
support. the old series 6326, 620, 530 don't have DRI support, but but
there are docs available (on the dri website I think) to write a DRI
driver; there was also a utah-glx
Mark Vojkovich wrote:
On Fri, 30 May 2003, Ian Romanick wrote:
Mark Vojkovich wrote:
I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function
to XvMC. I have implemented this in NVIDIA's binary drivers and
am able to do full framerate HDTV video textures on the higher end
GeForce4 MX
Alexander Stohr wrote:
From CVS/XFree86/xc/extras/Mesa/bin/Attic/glx86asm.py,v
revision 1.2
date: 2000/12/07 16:12:47; author: dawes; state: dead; lines: +0 -0
Remove from the trunk the Mesa files that aren't needed.
Latest entry in cvs log of c/extras/Mesa/src/X86/glapi_x86.S
revision 1.7
50 matches
Mail list logo
