jordan muscott wrote:
Greets all,
Linux-mandrake 8.1 , kernel 2.4.18
PIII
ati rage pro - mach64.
On the above setup i can get hardware acceleration with the Xfree 3.3.6
that came with my distro via GLX. I built Xfree 4.2 from the mandrake
8.2 src rpms because i read that the support for my
Rainer Blum wrote:
Hi,
my first question is about the antialiasing feature of
the ATI Radeon 9000 (called smoothvision):
How can I use/activate this feature under Linux?
AFIAK, not with the open-source drivers. I don't believe that ATI has
ever released documentation for this feature. I'm
Laura West wrote:
2. I am using Red Hat 7.2 and upgraded it to the latest kernel,
along with the latest version of xfree86. Trident Cyberblade is the
driver xfree86 chooses to be the best driver.
There is no hardware accelerated 3D driver available for this card for
Linux. The game
that has either open-source or closed-source drivers
comes in a PCI version.
---Original Message---
From: Ian Romanick [EMAIL PROTECTED]
Sent: 01/29/03 07:12 AM
To: [EMAIL PROTECTED]
Subject: Re: [XFree86] Problems with 3-D gaming on Redhat 7.2
Laura West wrote:
2. I am using Red
David Dawes wrote:
I think that's a little different from what is being discussed here.
I think it'd be good to make the reinit work you did more general (work
for all drivers), as well as make it possible for the DRI to adapt to
changes in video memory usage on the fly. Is your reinit patch in
Alessandro Cerri wrote:
Hi,
I just set up mandrake 9.0 with xfree 4.2.1 and tried to have dual head
working on my radeon 7000... the relevant XF86Config entries I believe
are correct (see bottom, am omitting irrelevant stuff).
I tried already:
- reinstalling XFree from the official xfree86
Damian Kokowski wrote:
./deimos/tmp/ut2003-demo. $ ./ut2003_demo
Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0.
OpenGL renderer relies on DXTC/S3TC support.
Update to the latest version of UT2k3. It drops the requirement for
S3TC support.
Florian Scandella wrote:
i recently installed xfree 4.3 and am experienceing a major slowdown
when running in a 24 bit resolution. as an example i played
neverwinternights with no problem, after the upgrade it only runs in 16
bit mode ( unless you like slideshows ). there are some problems with
[EMAIL PROTECTED] wrote:
I have downloaded the XFree86 4.3.0 source code and the mgadrivers-2.1-src
from matrox's web site. I am running linux kernel 2.4.20 with glibc-2.3.1
and gcc 3.2.1. do I need to copy the mgadrivers source into the xc
directory to compile them or do I need to copy them
Andrey P. Cherepenko wrote:
Hi,
I am looking for an appropriate mailing list to discuss 3D texture
implementation in hardware. Does anyone have any suggestions?
I am going to try 3D texture for volume visualization.
Could anybody tell me about good implementation 3D texture in hardware ?
What
[EMAIL PROTECTED] wrote:
I recently installed RH 9.0 and have been working on some
challenges with X. Some digging and experimentation has got
things mostly working. However, DRM won't load and this has
me stumpped for now.
Hardware:
ASUS TUSI-M, P3 @ 1GHz, SIS 630ET AGP chipset,
Stéphane Purnelle wrote:
On Mon, 2003-06-30 at 23:18, Ian Romanick wrote:
You have an Nvidia card. Did you load Nvidia's 3D drivers? If not, you
won't get any accelerated 3D. glxinfo is working perfectly.
What would you mean ?
Attention, i don't would like to install NVidia driver because
valli wrote:
I've installed Gentoo Linux 1.4_rc4 on my Pentium III machine.
(includes glibc-2.3.2 and xfree86-4.3.0)
Also part of my machine is the graphic card 'Diamond Fire GL2'.
But I didn't find a driver for this card and my glibc-version on
Martin Boris wrote:
i have buy an ati rage 128 because many site on the web say it's THE
linux compatible graphic card. No luck , my X server don't start.
And as i am not realy good with X i don't know what i can do.
I have found no answer in my debian Faq howto..
my config file can be found at:
Mark Lane wrote:
I am getting a weird error when attempting to run ForcePCIMode on an
opteron with a Radeon 7500 PCI. I have also used a 7000 with the same
results.
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020
(EE) RADEON(0):
Francisco J. Reyna Sepúlveda wrote:
Hi,
I cant make my Radeon Mobility work with 3d acceleration, I DONE
EVERYTHING please read.
1) Install XFree 4.x.x. Make sure it works. Backup !
DONE
Which .x.x did you install?
2) Check kernel messages to make sure agpgart and mtrr are being loaded
and
Francisco J. Reyna Sepúlveda wrote:
Hi,
My machine:
XFree86 Version 4.3.0 (Debian 4.3.0-0ds2.0.0woody1
OS Kernel: Linux version 2.4.21
ATI Technologies Inc Radeon Mobility M6 LY
What is the correct libGL.so.1.x I should be using?
ldd says /usr/X11R6/lib/libGL.so.1 when running ldd glxgears
John Lee wrote:
I am running XFree86 (v4.2.0) with fvwm2. If I turn backing store on in
my X Server, I run into the issue where my window decorations and pop-up
menus do not refresh properly. I have to paint them (ie move my mouse
over where the menu should be) in order for them to display.
Daniel Lang wrote:
could anyone state, if the Matrox Millenium P650 would work
with XFree 4.3.x on FreeBSD?
The G450/550 seem to be supported. Maybe the chipset is
compatible enough to work with the mga driver.
They are not similar at all. The P650 is based on the newer Parhelia
core. The only
Risenhoover, Paul wrote:
I've been trying to get DRI working on an ATI Mach64. It's running
RedHat 8.0 and I just used up2date to ensure I got all new code, plus
the new kernel. I've attached all the obligatory files for your review.
There's no official 3D driver for that card. There is an
manu wrote:
Hi all,
before I open a bug for that I would like to sort out things a bit.
Here is the story : I installed a MDK 9.2, the agpgart module seems to
be OK with my mobo (which has a nForce2 Ultra chipset), so I went on
and try to make 3D accel work for my Radeon 9200. Whereas all
manu wrote:
Le 30.10.2003 17:07:54, manu a écrit :
So I ran glxinfo see below which told me that Direct Rendering is not
enabled! This is crazy as you can check in the XFree log (file
attached).
Hope someone can tell me more about this, be it to file this directly
as a bug on bugzilla ;-)
Alan Hourihane wrote:
On Thu, Oct 30, 2003 at 05:07:33PM -0800, Ian Romanick wrote:
manu wrote:
Responding to myself : sorry it seems that the problem is because the
r200_dri.so module is linked against libexpat.so.1 which is not on my
system. So I just made a link to the one I had and all
Raymond Born wrote:
Will it ever work. Is there a way that it can already work?
It should already work. Various users and developers use this class of
ATI hardware on PPC without troubles. What problems are you having?
___
XFree86 mailing list
juggl3r wrote:
what is ppc? is it related in any way to 3d acceleration in ATI cards?
It's fairly common shorthand for PowerPC.
On Mon, 2003-11-10 at 18:22, Ian Romanick wrote:
Raymond Born wrote:
Will it ever work. Is there a way that it can already work?
It should already work. Various
GS HUNT wrote:
My first choice would to use the dirivers supplied by Xfree..
Xfree 4.3.0 has support for 3d ATI Drivers...which are almost as fast as the
ATI binaries... not to mention they are more stable..
However if you really need the ATI binaries... try downloading 3.2.8 fglrx
raf wrote:
I've got a problem. my DRI is not working. I dont know why, when i read
the log i found som unresolved sytmbol... but i dont know what that means.
glxinfo says: direct rendering: No and i would like to fix it.
I use: ATI Radeon 9000 Pro on slackware 9.1, Athlon 2000 xp. motherboard
raf wrote:
Hi
I've got a problem. my DRI is not working. I dont know why, when i read
the log i found som unresolved sytmbol... but i dont know what that means.
glxinfo says: direct rendering: No and i would like to fix it.
I use: ATI Radeon 9000 Pro on slackware 9.1, Athlon 2000 xp.
Patrick Dohman wrote:
I am having difficulties compiling the DRI tree on my redhat 8.0 system
running kernel 2.4.20-28 and XFree86 Red Hat Linux release 4.2.1-23. I
have been able to configure my video chip 845gl for a decent
resolution, however I do not have hardware acceleration so I figured I
Rahul Sawarkar wrote:
Hello
I've got a intel440bx with a Radeon7500 rv200 chip , running x4.3, on
kernel 2.6. System is built from source entirely.
One strange thing I noticed is that when I run glxgears in a small
window say 2x2 inch, cpu utilization jumps above 70%.
But when I maximise the
Rahul Sawarkar wrote:
When the card has to draw less pixels, a **larger** percentage of the
time is spent sending commands from the CPU to the card.
When the window is tiny, the card is drawing fewer pixels, but the CPU
has to send the **same** number of commands per
frame.
So are you saying
Phil Barnett wrote:
On Wednesday 10 March 2004 9:51 am, Alex Deucher wrote:
3D support for the IGP chipsets is available in DRI cvs. You can
either build from source or try the nightly binary snapshots available
here:
http://dri.sourceforge.net/cgi-bin/moin.cgi/Download
Cool, I'll try it out.
Paulo Belletato wrote:
I'm not understanding why that simple opengl program gives the message:
Xlib: extension XFree86-DRI missing on display :0.0.
You should be able to ignore that message. As part of libGL start-up it
tries to determine if direct rendering is available. With the
standard
Paulo Belletato wrote:
The problem is that the compiled program doesn't work properly.
A small window is created but it seems to be transparent. In fact It
copies the background.
That is odd. In an earlier message you said that you have an Nvidia
card. Did you ever install the Nvidia
Marcial Vieira wrote:
I tryed to configure my SiS 630 on-board with linux but 3D never worked,
glxinfo always output:
direct rendering: No
But XFree86.1.log has:
(II) SIS(0): [drm] installed DRM signal handler
(II) SIS(0): [DRI] installation complete
(II) SIS(0): [drm] installed DRM signal
Marcial Vieira wrote:
On Wednesday 31 March 2004 13:27, Ian Romanick wrote:
Based on the fact that glxinfo shows GLX version 1.4 is supported, you
must have installed the software libGL from Mesa. You need the libGL
that came with XFree86 to get hardware acceleration. Uninstall the Mesa
library
patrick boenzli wrote:
HW and SW datas:
Sony VAIO PCG-SR11K:
S3 Savage IX-MV, 8MB
Hardware accelerated 3D is not supported by any current X release on
that graphics chip. However, there is a driver in development. Please
look at:
Since this is most likely a DRI related issue, I'm cross-posting to
dri-devel.
Jeremy C. Reed wrote:
My wife's XFree86 was randomly crashing every once in a while. Not a good
thing.
I tracked it down to xscreensaver. I used xscreensaver-control and
manually tried different savers. It crashed on
Andy Goth wrote:
First I must point out that everything works alright when I don't use
DRI (more specifically, when I enable xinerama to disable DRI as a side
effect). So the card's fine and X is fine and my installation isn't
completely broken and my configuration must be right.
But with DRI I
Christian Brix Folsted Andersen wrote:
I am having trouble enabling 3D accelration on my laptop with ATI Radeon
Mobility M6.
System: Mandrake 10.0
Kernel: 2.6.8
When i run glxgears i get this error:
Xlib: extension XFree86-DRI missing on display :0.0
The framerate is only approx 200 fps and I
Aleksandar Donev wrote:
Hello,
It appears to me in principle the xfree86 implementation of GLX is up to
1.3 and supports pbuffers. However, I have not been able to find even a
single example on the web that I can use as a test. I am trying to
follow the GLX 1.3 specs and it is not working (the
Cornelis Bockemuehl wrote:
My hardware is an IBM Thinkpad R32, and IBM specifies the graphic adapter
as follows:
ATI Mobility Radeon 7000, AGB 4x, 16MB DDR-SDRAM, 66 MHz bus
On the ATI webpage I find the following graphic chip, which might (or might
not??) be the same:
ATI Mobility Radeon 7000 IGP
Cornelis Bockemuehl wrote:
Hello Ian,
Thanks for your explanation!
So the bottom line for me:
- IGP and M6 is not the same chip
Correct.
- Since I only find IGP in the radeon driver documentation for
XFree86, while my own system has an M6, which is not mentioned, there
is a good chance that it is
Brian Paul wrote:
Bukie Mabayoje wrote:
This is a mesa issue.
Willing, John (J.K.) wrote:
While running with a commercial CAD program, we encountered a problem
with the OpenGL libraries.
In Function DoMakeCurrent
640 if (prevglxc) {
641 if (prevglxc-drawPixmap) {
642 if
Bukie Mabayoje wrote:
The file is located Mesa/src/glx/x11 in your tree
and xc/programs/Xserver/GLglx in the Xfree86 tree.
But they are both out of sync. My Assumption is that Xfree86 uses the mesa
stuff. I may be wrong.
While they have the same name, those files are different. The one in
Jesse Nichols wrote:
New to linux, but just installed FC3 on a P3-450, 256mb ram, 40gig HD,
Radeon7000pci card.
FC3 uses X.org instead of XFree86, so this is actually the wrong list. :(
The installation went great. Desktop looks great, works fine.
The problem is that all the GL screensavers
Timo Saarinen wrote:
I have Matrox G550 card installed. The operating system is Debian Linux
Testing and there is hal driver (mgadriver-4.1) from Matrox installed
because it allows using digital cable.
When running glxinfo with LIBGL_DEBUG=1 the following error message is
printed: libGL
Nicholas Sushkin wrote:
I recently compiled and installed XFree86 4.5.0 on Linux. Now I am trying to
compile KDE, but it complains that libGL.la is missing. Isn't this file
supposed to be installed by XFree86? Is it a bug that libGL.la wasn't
generated by the install?
libGL is installed as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
soumya de wrote:
(EE) I810(0) :AGP GART support is not available. Make
sure your kernel has agpgart support or that the
agpgart kernel module is loaded.
I'm not 100% positive, but I believe this is accurate. The AGP
controller of the i8xx
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Osborn wrote:
I need Mesa's Glut, which didn't come with XFree86-4.5.0.
Mesa includes Mark Kilgard's original GLUT. That has license issues
that some find objectionable, so most Linux distros and (presumably)
XFree86 don't ship it.
If you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joel CARNAT wrote:
If I setup an xdm server (on the NetBSD machine) and connect to it from
a Linux machine (where the commercial drivers is installed), do I get 3D
accel with the remote session.
Another way to put that is, when using XDMCP, do
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
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
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
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
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
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
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
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
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...
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
1 - 100 of 111 matches
Mail list logo
