This is a patch to call the context handles destructors and free the
context bitmap entries when a process does not destroy its contexts
before it exits. It saves context handles in a linked list in the
drm_device struct. I decided to use per device list instead of a per
file descriptor list f
ADMIN: ignore my foobar'd post
--
Note also from a Quakeforge developer,
WildCode: maybe you should mention my r100 gets ~44 fps :) (hang on
and I'll get a fresh run)
make that 42, with -nosound (39 with sound)
actually, I'm using a rather old dri
So the gigabyte binary windows drivers for this Radeon 9200SE (AGP) card are
faulty, and it really should perform the same as the PCI Radeon 9000?
> I would expect them to perform about the same, with the
> AGP bus providing a slight performance boost. To be honest, I'm not
> sure why your window
--- Chris Ison <[EMAIL PROTECTED]> wrote:
> I brought an AGP Radeon 9200SE yesterday, thinking I would get a HUGE
> performance increase over my older PCI Radeon 9000. And for windows
> sure enough, the overkill demo in quakeforge jumped from 33fps to
> 122fps within Windows.
>
> When I tried it
I brought an AGP Radeon 9200SE yesterday, thinking
I would get a HUGE performance increase over my older PCI Radeon 9000. And for
windows sure enough, the overkill demo in quakeforge jumped from 33fps to 122fps
within Windows.
When I tried it in linux, the framerates for the
PCI R9000 were
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> Hello S3 Savage users,
>
[snip]
Felix,
I'd like to give you a hand on the 3D driver while I still have some
free time, but I have to admit, I'm somewhat intimidated. What's a
good task that I can work on to get my feet wet on the 3D side? It's
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> Hello S3 Savage users,
>
>
[snip]
>
> 3. Separate commands and data
>
> Right now commands and data are submitted to the chip as one data
> stream, either via the BCI or via DMA buffers. For easier security
> checking command and data streams shoul
At 06:25 PM 19/2/2004, Felix Kühling wrote:
Hello S3 Savage users,
---snip---
From the list below I'm going to do (1) and (2) pretty soon. Basically
I'd like to do all of this, all at the same time, if I could. But I have
other things that need attention too. So anybody who has some spare time
Hello S3 Savage users,
The most basic grunt work on the Savage 3D driver has been done in the
last three months. The driver was ported to Mesa 5 and support for the
Savage3D chip family was added. The result is available in CVS on the
savage-2-0-0-branch in DRI CVS. Now I consider the driver prett
[snip]
> diff -urN /tmp/wiki.qjQHTM/wiki/text/Troubleshooting
> /home/groups/d/dr/dri/wiki/text/Troubleshooting
> --- /tmp/wiki.qjQHTM/wiki/text/Troubleshooting2003-10-01 11:14:08.0
> -0700
> +++ /home/groups/d/dr/dri/wiki/text/Troubleshooting 2004-02-18 18:54:27.0
> -0
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
[EMAIL PROTECTED] changed:
What|Removed |Added
--
At 02:36 PM 18/2/2004, Felix Kühling wrote:
I didn't find any similar string in the driver. It's probably coming
from GLtron.
I committed another fix today. Can you cvs upgrade, enable DMA in
savagedma.h and try if it still locks up in the chromium BSU menu?
Ok, i did that and it still locks up in
Alan Cox wrote:
On Iau, 2004-02-19 at 03:10, Erdi Chen wrote:
Is this a known problem? Has it been fixed? I have to add a linked list
to VIA's DRM to keep track of context handles and perform clean up when
release is called on the DRI file descriptor. I will gladly create a
patch if this is a r
Hi Sérgio,
first off, I appreciate your interest in the savage driver and your
initiative. I'll comment on your proposals below. I'm going to send sort
of a savage roadmap to the list soon which will outline my plans for the
3D driver for the next couple of months. I'm sure there will be items on
On Thu, 19 Feb 2004 11:24:27 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> On Iau, 2004-02-19 at 02:02, Alex Deucher wrote:
> > 2D: do to a bug in S3's code, 2D accel was never enabled when the DRI
> > was active. I've managed to get 2D accel working again. one question
> > I have, I assume xf86In
I compared sources of Mesa-5.0.2 final release
http://prdownloads.sourceforge.net/mesa3d/MesaLib-5.0.2.tar.gz?download
http://prdownloads.sourceforge.net/mesa3d/MesaDemos-5.0.2.tar.gz?download
with mesa on this tree, the sources are not exactly equal, so I send to
you my proposal patch to put sour
On Iau, 2004-02-19 at 02:02, Alex Deucher wrote:
> 2D: do to a bug in S3's code, 2D accel was never enabled when the DRI
> was active. I've managed to get 2D accel working again. one question
> I have, I assume xf86InitFBManager() should only manage memory for 2D
> stuff? Otherwise it would conf
On Iau, 2004-02-19 at 03:10, Erdi Chen wrote:
> Is this a known problem? Has it been fixed? I have to add a linked list
> to VIA's DRM to keep track of context handles and perform clean up when
> release is called on the DRI file descriptor. I will gladly create a
> patch if this is a real probl
18 matches
Mail list logo