the subject says it: glxgears (and all other OpenGL-based programs)
abort with the message:
drmR128SwapBuffers = -14
My configuration:
Kernel 2.4.6
XFree86 4.1.0
ATI AIW 128 Pro
newly compiled drm kernel modules, r128 XFree86 driver, r128_dri.so,
etc.
Do you have the DRM from kernel
* accelerated 3d: glxgears are funny - they do not rotate, but
toggle from one position to another
My thought on this is that the gears are moving so fast that the only frames
that you actually get to see are of two alternating positions. The glxgears
program moves the gears a set
Dear DRI developers,
I read in the FAQ, that NVidia provide their own
binary closed source drivers. Yet visiting the Nvidia
homepage driver section I find, that there are not only
binary drivers for several distributions, but also a source
rpm and a source tarball for those interested.
* Johannes Prix ([EMAIL PROTECTED]) wrote:
Dear DRI developers,
I read in the FAQ, that NVidia provide their own
binary closed source drivers. Yet visiting the Nvidia
homepage driver section I find, that there are not only
binary drivers for several distributions, but also a source
rpm
On Fri, Oct 05, 2001 at 05:36:49PM +0200, Johannes Prix wrote:
I read in the FAQ, that NVidia provide their own
binary closed source drivers. Yet visiting the Nvidia
homepage driver section I find, that there are not only
binary drivers for several distributions, but also a source
rpm and a
The NV source is their kernel driver. This basic function
of this routine is to manage DMA transfers of buffers full
of graphics commands to the board. This is a very small
piece of code that exposes almost nothing of the architecture
of the graphics engine. The code that actually
builds the
The only source files that nVidia provides are very limited files for
compiling the necessary kernel driver (which, from what I understand,
contains very little info regarding nVidia's hardware). The source rpm
they have for NVIDIA_GLX is nothing more than the compiled libraries and X
On Friday 05 October 2001 10:46, you wrote:
i noticed your name on dri.sourceforge.net and was wondering if mach64
support was still being worked on or if the developers aren't going to
continue with the project. there are many questions about it in
I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to
be the most stable accellerator) but for lack of experience and not much of a place to
start..
On the other hand, I'm getting paid to do it (part of my job), so chances are I'll
complete it.
Any pointers
Maybe I'm just paranoid, but why so much on the i810? This chipset is
slower than Mach64, and people never got it in the intention of doing
games, or other intense graphics.
Roberto Peon wrote:
I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to
be the most
In our case, it isn't necessarily on the i810. We don't really care what accellerator
is used as long as it works well for textures and stenciling. Depth buffering is a
bonus, but not necessary for the majority of things that we do. Dest alpha, on the
other hand IS.
Right now we're evaluating
Hi,
I have a Dell Inspiron 4000 with an ATI Rage Mobility M3 on which DRI doesn't
work. The r128 module loads fine, when I try to read from /proc/dri/0/vm,
cat segfaults and I get this oops:
ksymoops 2.4.3 on i686 2.4.9-ac18. Options used
-V (default)
-k /proc/ksyms (specified)
On Sat, Oct 06, 2001 at 02:46:44AM +0200, Dagfinn Ilmari Mannsåker wrote:
Hi,
I have a Dell Inspiron 4000 with an ATI Rage Mobility M3 on which DRI doesn't
work. The r128 module loads fine, when I try to read from /proc/dri/0/vm,
cat segfaults and I get this oops:
With 2.4.10-ac7 it no
Before I try delving deeper into this, maybe someone can tell me what is
going on.
* Radeon: 1002:5144
* 2d is working fine
* software GL is working fine
* accelerated 3d: glxgears are funny - they do not rotate, but
toggle from one position to another
* when I move
14 matches
Mail list logo
