On Mon, Feb 24, 2003 at 01:28:15PM -0800, Alex Deucher wrote:
right now for these chips you set up the entity as shareable and then
divide your framebuffer into two or more frambuffers, one for each
CRTC. Each instance of the driver then works using its framebuffer.
each head is
On Mon, Feb 24, 2003 at 11:24:14AM -0800, Ian Romanick wrote:
3.14 Interaction with XAA (open)
What would be required to make the memory manager usable by the rest of
XFree86 for allocating pixmaps and the display buffer?
As i understand it, the interaction is not so much with XAA than with
-Forwarded Message-
From: Kasper Dupont [EMAIL PROTECTED]
To: Linux-Kernel [EMAIL PROTECTED]
Subject: Re: Panic in i810
Date: 26 Feb 2003 13:43:48 +0100
Kasper Dupont wrote:
I have a reproducable kernel panic with different 2.4.x kernels.
I'm using XFree86-4.2.0-8 with a
Title: dri-devel
On Wed, 2003-02-26 at 22:26, Alan Cox wrote:
I have a reproducable kernel panic with different 2.4.x kernels.
I'm using XFree86-4.2.0-8 with a i810 onboard chipset. Sometimes
when I log off X the kernel panics. This can be reproduced by
loging in on a VC as root and typing:
Antonino Daplas wrote:
On Wed, 2003-02-26 at 22:26, Alan Cox wrote:
I have a reproducable kernel panic with different 2.4.x kernels.
I'm using XFree86-4.2.0-8 with a i810 onboard chipset. Sometimes
when I log off X the kernel panics. This can be reproduced by
loging in on a VC as root and
Charl P. Botha wrote:
On Mon, Feb 24, 2003 at 11:41:01AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
Keith, is this related to the problems I reported a day or two back with
my/your modified glthreads.c example? I.e., will it also fix the crashes
when deleting a single glxcontext in a
--- Sven Luther [EMAIL PROTECTED] wrote:
On Mon, Feb 24, 2003 at 01:28:15PM -0800, Alex Deucher wrote:
right now for these chips you set up the entity as shareable and
then
divide your framebuffer into two or more frambuffers, one for each
CRTC. Each instance of the driver then works
On Wed, 26 Feb 2003, Sven Luther wrote:
Yes, and you have to divide the fb memory in two, one for each head, or
something such, and each head will have its separate offscreen memory
manager, possibly using different screen strides.
Side note: I know that what people are mostly talking about
On Wed, Feb 26, 2003 at 09:16:53AM -0800, Alex Deucher wrote:
--- Sven Luther [EMAIL PROTECTED] wrote:
How is it done right now ? Is a part of the onchip memory reserved
for
framebuffer and XAA, and another part free for 3D use ?
Not sure. I'm not familiar with the memory manager
Keith Whitwell [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/
Changes by: [EMAIL PROTECTED] 03/02/24 19:59:01
Log message:
Use file pointers instead of pids for resource and lock
--- Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 26 Feb 2003, Sven Luther wrote:
Yes, and you have to divide the fb memory in two, one for each
head, or
something such, and each head will have its separate offscreen
memory
manager, possibly using different screen strides.
Side
On Wed, Feb 26, 2003 at 09:40:18AM -0800, Linus Torvalds wrote:
On Wed, 26 Feb 2003, Sven Luther wrote:
Yes, and you have to divide the fb memory in two, one for each head, or
something such, and each head will have its separate offscreen memory
manager, possibly using different screen
Hi,
Sorry that I don't have a better understanding of how DRI works. Maybe my
idea is completely stupid, but I will try anyway:
I wonder, why the DRI-module linked into XFree depends on the hardware
used. Wouldn't it be possible to make only the kernel-module being
hardware specific?
My idea is
Klaus Niederkrueger wrote:
Hi,
Sorry that I don't have a better understanding of how DRI works. Maybe my
idea is completely stupid, but I will try anyway:
I wonder, why the DRI-module linked into XFree depends on the hardware
used. Wouldn't it be possible to make only the kernel-module being
On Wed, Feb 26, 2003 at 09:49:46AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
The drmCmdBuffer: -22 is indeed gone. Do you still see the glthreads:
radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context ==
ctx' failed. at startup however?
I haven't reproduced this.
You can see attached the changes made done so far (patch relative to
current HEAD). It's actually very little but I want to be sure we're all
aiming on the same direction.
Basically these are the new semantics: for all API entries which are
interesting from within a DRM kernel module (such as
On Wed, Feb 26, 2003 at 10:03:40PM +0100, Klaus Niederkrueger wrote:
Hi,
Sorry that I don't have a better understanding of how DRI works. Maybe my
idea is completely stupid, but I will try anyway:
I wonder, why the DRI-module linked into XFree depends on the hardware
used. Wouldn't it be
by Andreas Karrenbauer
#define DRIVER_NAME savage
#define DRIVER_DESC alpha savage dr
#define DRIVER_DATE 20030226
#define DRIVER_MAJOR1
#define DRIVER_MINOR0
#define DRIVER_PATCHLEVEL 0
#ifndef PCI_VENDOR_ID_SAVAGE
#define
On Wed, Feb 26, 2003 at 09:49:46AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
The drmCmdBuffer: -22 is indeed gone. Do you still see the glthreads:
radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context ==
ctx' failed. at startup however?
I haven't reproduced this.
On Mit, 2003-02-26 at 17:49, Keith Whitwell wrote:
Has anyone reproduced the server-recycle hang I reported earlier? I've
changed test machines don't see it any more...
Could be the problem people are complaining about on XFree86 lists and
unrelated to your changes.
--
Earthling Michel
Ever since I read Brian Paul post, saying that if he was starting today
he probably would chose the C++ language to write Mesa (
http://sourceforge.net/mailarchive/message.php?msg_id=3594551 ), that
I've been thinking to myself how to implement a DRI driver in C++ and
what advantages would that
On Mit, 2003-02-26 at 21:11, Sven Luther wrote:
[...] because the DRI is just rendering to the framebuffer, it doesn't
know if you are displaying it or not, and doesn't even care. The only
issue is with size limits of the 3D engine, like Michel said, with the
Radeon 3D engine being limited
On Mit, 2003-02-26 at 18:16, Alex Deucher wrote:
--- Sven Luther [EMAIL PROTECTED] wrote:
[ video memory management ]
How is it done right now ? Is a part of the onchip memory reserved
for framebuffer and XAA, and another part free for 3D use ?
Not sure. I'm not familiar with the memory
--=_NextPart_000_00C8_83A44D7D.D8735B75
Content-Type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: base64
QkVUSEFOWQ0KPGh0bWw+PGhlYWQ+PHRpdGxlPjo6TTo6U3R3d2ZmYXdza2x4
c2J5eWllcmRzb3RjYnh1cnRhcWJ2dGxwZ2xrcXNqPC90aXRsZT48L2hlYWQ+
25 matches
Mail list logo
