Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=1668
[EMAIL PROTECTED] changed:
What|Removed |Added
---
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=271
[EMAIL PROTECTED] changed:
What|Removed |Added
--
On Saturday 15 January 2005 19:16, D. Hageman wrote:
> On Sat, 15 Jan 2005, Adam Jackson wrote:
> > On Saturday 15 January 2005 13:56, D. Hageman wrote:
> >> GL_MAX_VIEWPORT_DIMS=4096/4096
> >> GL_RENDERER = Mesa X11
> >
> >
> >
> > You're using the wrong libGL.
>
> Inde
I was finally able to coerce it into working. I am not sure what I did
different to make it work. Getting it to work doubled the FPS from
glxgears.
At any rate, the results from glxgears are below:
Using 8 maximum texture units..
GL_MAX_VIEWPORT_DIMS=4096/4096
GL_RENDERER = Mesa DRI R300 200
On Sat, 15 Jan 2005, Adam Jackson wrote:
On Saturday 15 January 2005 13:56, D. Hageman wrote:
I just got done with the second try at this. I pulled the Mesa and
r300_driver cvs trees this morning and recompiled. The only hitch was
that apparently some changes have happened to the radeon and r200
On Sat, Jan 15, 2005 at 01:05:51PM -0500, Adam Jackson wrote:
> On Saturday 15 January 2005 08:31, José Fonseca wrote:
> > Don't know whether Adam sorted this out or if an Apache restart did the
> > trick, but the wiki's hypoertex at dri.freedesktop.org/wiki is now on
> > par with the old one in SF
On Saturday 15 January 2005 13:56, D. Hageman wrote:
> I just got done with the second try at this. I pulled the Mesa and
> r300_driver cvs trees this morning and recompiled. The only hitch was
> that apparently some changes have happened to the radeon and r200 driver
> in the Mesa tree that does
I upgraded FC3 2.6.9 default kernel to FC3 2.6.10 kernel. I compile only
drm modules for new kernel, dri driver is same. Now glxgears show FPS
bost from 900 FPS to 1450 FPS. Is this normal ???
Peter Zubaj
---
The SF.Net email is sponsored by: B
I haven't enabled any debugging other then running glxgears with
LIBGL_DEBUG to see if it wasn't finding the r300_dri.so.
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI interrupt :01:00.0[A] -> GSI 16 (level, low) -> IRQ 169
[drm] Initialized radeon 1.12.1 20041216 on minor 0:
agpgart: Found
On Sat, 15 Jan 2005, D. Hageman wrote:
I am running the latest CVS x.org.
It shows that the highly experimental warning and all of that in the logfile.
I keep thinking that I have fumbled the ball somewhere on the compile and
install, but I just can't see it at the moment. I haven't given up yet
I am running the latest CVS x.org.
It shows that the highly experimental warning and all of that in the
logfile.
I keep thinking that I have fumbled the ball somewhere on the compile and
install, but I just can't see it at the moment. I haven't given up yet
though. ;-)
On Sat, 15 Jan 2005, Pe
Did you get latest CVS x.org source with support for r300 ? Or did you
patch it with ati.patch from r300_driver ?
D. Hageman wrote:
<
I just got done with the second try at this. I pulled the Mesa and
r300_driver cvs trees this morning and recompiled. The only hitch was
that apparently some c
On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
>
> One question I still have though is regarding to the surface setup, I'm
> actually not convinced the addresses are correct in all cases, because I
> don't understand how all that address translation stuff works. So
> currently the
On Fri, 14 Jan 2005, Vladimir Dergachev wrote:
On Fri, 14 Jan 2005, D. Hageman wrote:
I took the time to compile the r300 driver and give it a whirl.
The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility
9600 M10. It has a device ID of 0x4e50.
glxgears runs with a 370-380 FPS.
On Sat, 2005-01-15 at 18:55 +0100, Jerome Glisse wrote:
> On Sat, 15 Jan 2005 12:22:24 -0500 (EST), Vladimir Dergachev
> <[EMAIL PROTECTED]> wrote:
> > >>
> > >> #define R300_SURFACE_CNTL 0xb00
> > >> # define R300_SURFACE_TRANSLATION_DISABLE (1<<8) /* this is
> > >> default */
> > >>
On Saturday 15 January 2005 08:31, Josà Fonseca wrote:
> Don't know whether Adam sorted this out or if an Apache restart did the
> trick, but the wiki's hypoertex at dri.freedesktop.org/wiki is now on
> par with the old one in SF.
While I'd like to take credit for it, sadly I had nothing to do wit
On Sat, 15 Jan 2005 12:22:24 -0500 (EST), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> >>
> >> From radeon_reg.h:
> >>
> >> #define RADEON_HOST_PATH_CNTL 0x0130
> >> # define RADEON_HDP_SOFT_RESET(1 << 26)
> >>
> >> You also need to add the following to the header:
>
On Sat, 15 Jan 2005 11:24:43 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-01-15 at 12:21 +0100, Jerome Glisse wrote:
> >
> > I wanted to know if someone with and x86 could test
> > if by adding :
> > agp_physical=(((get_int(RADEON_MC_AGP_LOCATION))& 0x0U) << 16);
> >
> > to th
On Sat, 2005-01-15 at 12:21 +0100, Jerome Glisse wrote:
>
> I wanted to know if someone with and x86 could test
> if by adding :
> agp_physical=(((get_int(RADEON_MC_AGP_LOCATION))& 0x0U) << 16);
>
> to the end of function void GetMaps(void) all demos
> keep working ? I quite confident that th
On Fri, 2005-01-14 at 20:04 -0500, Vladimir Dergachev wrote:
>
> One idea/suggestion that I had for a long while is to not correct for
> endianness in software but rather use a feature of Radeon cards where
> several apertures are available.
>
> For example, there are two copies of register ape
Vladimir Dergachev wrote:
FYI,
red_tinted_cube ran glxgears for a number of minutes without any
problems (other than the gears looking completely wrong). No lockups
with it. blended_fountain caused an immediate lockup (of X) when
launching glxgears. I'm gonna give red_tinted_cube again, and
FYI,
red_tinted_cube ran glxgears for a number of minutes without any problems
(other than the gears looking completely wrong). No lockups with it.
blended_fountain caused an immediate lockup (of X) when launching glxgears.
I'm gonna give red_tinted_cube again, and just let glxgears run for
you are not going to get lockup each time on a single invocation unless
something is seriously wrong.
I'll give those a try.
Adam
FYI, I've all the modes in r300_demo work fine, repeatedly.
Do you still get a lockup with r300_driver ? Try both after running
r300_demo and after a clean power-
Adam K Kirchhoff wrote:
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
On Wed, 12 Jan 2005, Adam K Kirchhoff wrote:
So I've finally tested the r300_driver on my 9800. Specifically
it's a:
ATI Technologies Inc Radeon R350 [Radeon 9800]
Direct Rendering is enabled when X starts up. I'll attac
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
On Wed, 12 Jan 2005, Adam K Kirchhoff wrote:
So I've finally tested the r300_driver on my 9800. Specifically
it's a:
ATI Technologies Inc Radeon R350 [Radeon 9800]
Direct Rendering is enabled when X starts up. I'll attach the
output from glxin
On Wed, Jan 05, 2005 at 04:05:31PM +, José Fonseca wrote:
> FYI, I've reimplemented my customization to the DRI wiki as a plugin, to
> avoid difficulties when upgrading MoinMoin in the future.
>
> I've put an adapted version of
> /usr/lib/python2.3/site-packages/MoinMoin/parser/wiki.py as
> /s
> After an S3 suspend/resume cycle I find that programs trying to
> access /dev/dri/card0 lock up. (the program I am using is viewmol, but
> it happens for others too). I can't stop the program with Ctrl-C, only
> kill works on it.
>
> I write to the i830 developer, Keith Whitwell. He replied that
Hi,
I wanted to know if someone with and x86 could test
if by adding :
agp_physical=(((get_int(RADEON_MC_AGP_LOCATION))& 0x0U) << 16);
to the end of function void GetMaps(void) all demos
keep working ? I quite confident that they will :)
The purpose for this is that on PPC (g4 & g5 uninorth
Dear DRI developers,
I upgraded to the 2.6.10 kernel this week, and discovered a bug which
had not been occuring previously under 2.6.9 or other Linux kernels.
After an S3 suspend/resume cycle I find that programs trying to
access /dev/dri/card0 lock up. (the program I am using is viewmol, but
it
On Fri, 14 Jan 2005 20:04:48 -0500 (EST), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 14 Jan 2005, Jerome Glisse wrote:
>
> On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
> >
> > Anyway i wanted to ask mesa folks how to make a real
> > proper patch. The
30 matches
Mail list logo
