Removing the
Option "XvMCSurfaces" "6"
from my XF86Config file seems to make everyone a bit happier again...
will do some more testing tomorrow to make sure this is what was causing
it ..
and I meant glxgears from RH7.3.. hands were ahead of brain yesterday..
Well for me this means I'll lose t
Title: Get a Personal Rate Quote Tired of getting a generic rate quote
Let lenders compete for
your
business!
Well the i830 page flip code is using async flips, the main thing I want
to use page flipping for on my i815 is sync'ed flips so I don't see the
tearing that is so really obvious and gives people headaches.. (don't need
to be getting sued here!!).
It's not the timing I'm worried about it's the te
On Die, 2002-12-17 at 02:53, David Dawes wrote:
> >I don't know the story behind the removal of RADEONSaveFBDevRegisters() --
> >seems to be related to keeping pageflipping working over an fbdev call. Can
> >anyone comment on whether or not this is still necessary?
>
> I expect that got accide
On Mon, Dec 16, 2002 at 10:01:18PM +0100, Michel Dänzer wrote:
>On Mon, 2002-12-16 at 20:52, Martin Spott wrote:
>> > O.k, I'll do a rebuild this evening - although I might not be able to verify
>> > a screenshot before tomorrow,
>>
>> Hmmm - unfortunately, after (I think) David's unsuccessfull m
On Tue, Dec 17, 2002 at 01:02:45AM +, Keith Whitwell wrote:
>David Dawes wrote:
>> On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote:
>>
>>>On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
>>>
On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote:
>CVSROOT: /
On Die, 2002-12-17 at 01:42, Martin Spott wrote:
> > There are sporadic rendering bugs in FlightGear, however. Every ~40
> > frames or so, I'll see a large triangle or two flash on the screen.
>
> Like these ones ?
>
> http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png
>
>
> I
On Die, 2002-12-17 at 01:36, David Dawes wrote:
>
> The SourceForge admins cleared the locks, and I've finshed committing
> the merge. The part of this merge that I'm least sure of is the 2D
> radeon driver.
>
> It'd be a big help if someone could take a look at the merged code and
> let me know
David Dawes wrote:
On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote:
On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/sha
On Mon, Dec 16, 2002 at 12:49:27PM -0800, Linus Torvalds wrote:
>
> On Mon, 16 Dec 2002, Keith Whitwell wrote:
> > >
> > > 1) Provide a set of DRM APIs for PCI DMA buffers allocation. No
> > > assumption about the buffer management is made and that is entirely left
> > > to the DRM driver (which
> There are sporadic rendering bugs in FlightGear, however. Every ~40
> frames or so, I'll see a large triangle or two flash on the screen.
Like these ones ?
http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png
I see them all the time at least after take-off and a slight left tur
On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote:
>On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
>>On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote:
>>> CVSROOT:/cvsroot/dri
>>> Module name:xc
>>> Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shar
On Mon, Dec 16, 2002 at 07:20:16PM +0100, Michel Dänzer wrote:
> On Mon, 2002-12-16 at 19:09, Martin Spott wrote:
> > On Mon, Dec 16, 2002 at 06:44:46PM +0100, Michel Dänzer wrote:
> > > Is the 4.0.4 screenshot from after I merged fixes from the trunk?
> >
> > I believe so. The screenshot dates o
On Mon, Dec 16, 2002 at 08:09:28PM +, Keith Whitwell wrote:
> José Fonseca wrote:
[...]
> What's important to see is that buffers are three things:
> 1) a memory management system
> 2) a hardware synchronization device
> 3) a mechanism for submitting commands to hardware
>
>
Both drivers get terribly confused if the other one touches the card
first. I typically have to do a hard reset before changing X servers
or else the machine chokes (sometimes it's a hard lockup, other times
the X server just enters an infinite loop and I can reboot the machine
over the netwo
On Mon, 2002-12-16 at 21:10, Andy Ross wrote:
>
> First off, getting DRI to coexist with an existing X11 distribution is
> a chore. As everybody knows (translation: I only wasted 20 minutes on
> this one) clients have to have an LD_LIBRARY_PATH containing the right
> libGL.so, but even then you o
On Tue, Dec 17, 2002 at 12:14:53AM +0100, Michel Dänzer wrote:
> On Mon, 2002-12-16 at 21:58, magenta wrote:
>
> > http://www.cs.nmsu.edu/~joshagam/Solace/
>
> Looks very interesting, is there a chance for a Linux/PPC build?
If someone were to lend me a Linux/PPC machine to compile it on. :D Or
On Mon, 2002-12-16 at 21:58, magenta wrote:
> http://www.cs.nmsu.edu/~joshagam/Solace/
Looks very interesting, is there a chance for a Linux/PPC build?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enth
Am Montag, 16. Dezember 2002 22:59 schrieb Brian Paul:
> Andy Ross wrote:
> > Actually, I'm fuzzy on the spec here. The DRI (and NVidia) drivers
> > appear to *not* sample the texture border color by default when
> > drawing quads with texture coordinates of exactly 1 and 0. The ATI
> > ones see
Andy Ross wrote:
I finally got a chance over the weekend to try out the current DRI
code on my new 8500 card and compare it with the offering from ATI.
The following is a cheers & jeers style review. Hopefully someone
will find it helpful.
My setup: 950MHz Athlon (early/pre-thunderbird), KT133 m
Andy Ross wrote:
Keith Whitwell wrote:
Andy Ross wrote:
Is it possible [...] to get the client-side libGL to look somethere
*other* that /usr/X11R6/lib/modules/dri for drivers?
It's LIBGL_DRIVERS_PATH
Perfect. Thanks.
You also don't exhibit a texture border bug that the ATI drivers
ha
On Mon, Dec 16, 2002 at 01:04:18PM -0800, Andy Ross wrote:
> Keith Whitwell wrote:
> > Andy Ross wrote:
> > > Is it possible [...] to get the client-side libGL to look somethere
> > > *other* that /usr/X11R6/lib/modules/dri for drivers?
> >
> > It's LIBGL_DRIVERS_PATH
>
> Perfect. Thanks.
>
> >
Keith Whitwell wrote:
> Andy Ross wrote:
> > Is it possible [...] to get the client-side libGL to look somethere
> > *other* that /usr/X11R6/lib/modules/dri for drivers?
>
> It's LIBGL_DRIVERS_PATH
Perfect. Thanks.
> > You also don't exhibit a texture border bug that the ATI drivers
> > have
>
>
On Mon, 2002-12-16 at 20:52, Martin Spott wrote:
> > O.k, I'll do a rebuild this evening - although I might not be able to verify
> > a screenshot before tomorrow,
>
> Hmmm - unfortunately, after (I think) David's unsuccessfull merge attempts,
> the 4.0.4-branch does not build:
>
> radeon_ioctl.
On Mon, Dec 16, 2002 at 12:10:03PM -0800, Andy Ross wrote:
>
> ATI blows you guys away in glxgears. I see 38% faster frame rates
> with their drivers. Since I doubt gears is doing anything but
> glVertex calls (someone correct me if I'm wrong), I take this to mean
> that there's significant room
On Mon, 16 Dec 2002, Martin Spott wrote:
> > O.k, I'll do a rebuild this evening - although I might not be able to verify
> > a screenshot before tomorrow,
>
> Hmmm - unfortunately, after (I think) David's unsuccessfull merge attempts,
> the 4.0.4-branch does not build:
>
> radeon_ioctl.c:44:46
On Mon, 16 Dec 2002, Keith Whitwell wrote:
> >
> > 1) Provide a set of DRM APIs for PCI DMA buffers allocation. No
> > assumption about the buffer management is made and that is entirely left
> > to the DRM driver (which is free to put some in a linked list, map them
> > or whatever). In Linux th
On Mon, Dec 16, 2002 at 12:10:03PM -0800, Andy Ross wrote:
> You also don't exhibit a texture border bug that the ATI drivers have
> (also submitted to them; no response yet), so at least I know it's not
> a hardware limitation. Good work. :)
As near as I can tell, there are some OpenGL texture
Am Montag, 16. Dezember 2002 19:20 schrieb Michel Dänzer:
> On Mon, 2002-12-16 at 19:09, Martin Spott wrote:
> > On Mon, Dec 16, 2002 at 06:44:46PM +0100, Michel Dänzer wrote:
> > > > DRI with Mesa-4.0.4 - as suggested for shipping with XFree86-4.3:
[-]
> > > Well, it doesn't look that much bette
Andy Ross wrote:
I finally got a chance over the weekend to try out the current DRI
code on my new 8500 card and compare it with the offering from ATI.
The following is a cheers & jeers style review. Hopefully someone
will find it helpful.
My setup: 950MHz Athlon (early/pre-thunderbird), KT133 m
On Mon, 2002-12-16 at 20:09, Keith Whitwell wrote:
> > 1) Provide a set of DRM APIs for PCI DMA buffers allocation. No
> > assumption about the buffer management is made and that is entirely left
> > to the DRM driver (which is free to put some in a linked list, map them
> > or whatever). In Linux
This is just a friendly reminder that the weeking dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.openprojects.net at 2100 UTC (or
4:00PM EST or 1:00PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
-
> O.k, I'll do a rebuild this evening - although I might not be able to verify
> a screenshot before tomorrow,
Hmmm - unfortunately, after (I think) David's unsuccessfull merge attempts,
the 4.0.4-branch does not build:
radeon_ioctl.c:44:46: radeon_macros.h: No such file or directory
make[5]: **
I finally got a chance over the weekend to try out the current DRI
code on my new 8500 card and compare it with the offering from ATI.
The following is a cheers & jeers style review. Hopefully someone
will find it helpful.
My setup: 950MHz Athlon (early/pre-thunderbird), KT133 motherboard,
OEM 85
José Fonseca wrote:
This a proposal to give a more flexible approach to the current DRM's
generic DMA engine.
The current engine is described at
http://dri.sourceforge.net/doc/drm_low_level.html, section 2, item 3,
which I include here for your convenience:
1. The X server can specify multiple
Am Montag, 16. Dezember 2002 20:29 schrieb Martin Spott:
> On Mon, Dec 16, 2002 at 06:49:26PM +0100, Dieter Nützel wrote:
> > > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png
> >
> > None if these links works.
>
> Sorry, the University appears to have network trouble this evening,
Rudnev,
On Mon, Dec 16, 2002 at 07:01:20PM +0300, Rudnev A.D. wrote:
> I an extrimely intrested in developing DRI for S3 ProSavage DDR(and ready to
>participate in development). So I wanted to ask:
> 1)Is anybody developing(or already developed) such drivers .
> 2)If no, where
This a proposal to give a more flexible approach to the current DRM's
generic DMA engine.
The current engine is described at
http://dri.sourceforge.net/doc/drm_low_level.html, section 2, item 3,
which I include here for your convenience:
1. The X server can specify multiple pools of different s
On Mon, Dec 16, 2002 at 06:49:26PM +0100, Dieter Nützel wrote:
> > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png
>
> None if these links works.
Sorry, the University appears to have network trouble this evening,
Martin.
--
Unix _IS_ user friendly - it's just selective about
On Mon, Dec 16, 2002 at 07:20:16PM +0100, Michel Dänzer wrote:
> > > Is the 4.0.4 screenshot from after I merged fixes from the trunk?
> >
> > I believe so. The screenshot dates on "2002-12-13 18:04" (CET) and the CVS
> > update was taken very few hours before.
>
> I did the merge on Saturday th
On Mon, 2002-12-16 at 19:09, Martin Spott wrote:
> On Mon, Dec 16, 2002 at 06:44:46PM +0100, Michel Dänzer wrote:
>
> > > DRI with Mesa-4.0.4 - as suggested for shipping with XFree86-4.3:
> > >
> > > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png
> >
> > Is the 4.0.4 screenshot
On Mon, Dec 16, 2002 at 06:44:46PM +0100, Michel Dänzer wrote:
> > DRI with Mesa-4.0.4 - as suggested for shipping with XFree86-4.3:
> >
> > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png
>
> Is the 4.0.4 screenshot from after I merged fixes from the trunk?
I believe so. The s
Am Montag, 16. Dezember 2002 18:07 schrieb Martin Spott:
> Unfortunately my mail got lost last weekend, so I hope you forgive me this
> repost. I made three screenshots showing FlightGear on the default start
> position. My aim is to convince people of the advantages of the current DRI
> CVS trunk.
Third'ed belatedly... one of my friends just got an A7N266-VM and
has a Sapphire Radeon 7500, so without this code being activated (by
recompile) he can't use DRI... thankfully we can do that, but it'd be nice
to have it in XFree 4.3.0.
- Chad
On Thu, 5 Dec 2002, [iso-8859-15] J
On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
>On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote:
>> CVSROOT: /cvsroot/dri
>> Module name: xc
>> Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/
>> Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:4
On Mon, 2002-12-16 at 18:07, Martin Spott wrote:
> Unfortunately my mail got lost last weekend, so I hope you forgive me this
> repost. I made three screenshots showing FlightGear on the default start
> position. My aim is to convince people of the advantages of the current DRI
> CVS trunk.
>
> XF
On Mon, 16 Dec 2002, Martin Spott wrote:
>
> I _vote_ for Mesa-5.x - as you may imagine :-)
I really would like to see 4.3 use a _modern_ DRI, instead of using
something old and known broken. 4.3 will be around for a long time, which
means that if it's already stale now it will only be even _mo
Unfortunately my mail got lost last weekend, so I hope you forgive me this
repost. I made three screenshots showing FlightGear on the default start
position. My aim is to convince people of the advantages of the current DRI
CVS trunk.
XFree86-4.2 - as shipped with SuSE-8.1:
http://document.ihg.un
I an extrimely intrested in
developing DRI for S3 ProSavage DDR(and ready to participate in development).
So I wanted to ask:
1)Is anybody
developing(or already developed) such drivers .
2)If no,
where from can i take information on my chipsets system of commands(Is
disa
On Mon, 2002-12-16 at 14:21, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote:
> >
> >>I think maybe I decided copying was ok as long as:
> >>- you rig XAA (or whatever) to always draw into the current front buffer.
> >>- you use cliprects
On Sat, Dec 14, 2002 at 09:42:58AM +0300, Samium Gromoff wrote:
>There is one hopefully nice idea to help DRI developement.
> The first and best thing to make a project successful is a good and clean
> codebase. The second is a comprehensible set of docs in order to attract
> more develo
Michel Dänzer wrote:
On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote:
I think maybe I decided copying was ok as long as:
- you rig XAA (or whatever) to always draw into the current front buffer.
- you use cliprects to exclude the 3d window so that the backbuffer never
gets scribbled.
Righ
On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote:
>
> I think maybe I decided copying was ok as long as:
> - you rig XAA (or whatever) to always draw into the current front buffer.
> - you use cliprects to exclude the 3d window so that the backbuffer never
> gets scribbled.
Right, I
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
The 830 page flipping code is turned off for some good reasons:
- I
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
The 830 page flipping code is turned off for some good reasons:
- I
On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote:
> >
> >>Michel Dänzer wrote:
> >>
> >>>On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
> >>>
> >>>
> The 830 page flipping code is turned off for some good reason
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
The 830 page flipping code is turned off for some good reasons:
- I haven't seen it work without really visible corruption on the flip -
typicall
On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
> >
> >>The 830 page flipping code is turned off for some good reasons:
> >>- I haven't seen it work without really visible corruption on the flip -
> >>typically f
Michel Dänzer wrote:
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
The 830 page flipping code is turned off for some good reasons:
- I haven't seen it work without really visible corruption on the flip -
typically flashing and blank areas
Presumably it uses the mi shadow module, and you
On Mon, 2002-12-16 at 06:23, Dave Airlie wrote:
> Dave Airlie said:
> >
> >> Which application is this?
>
> glxgears from RH4.2 blows it away also!!
Some time ago, the r128 driver (or maybe all drivers) showed incorrect
rendering when running without a window manager. Maybe this is related?
Unfor
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
>
> The 830 page flipping code is turned off for some good reasons:
> - I haven't seen it work without really visible corruption on the flip -
> typically flashing and blank areas
Presumably it uses the mi shadow module, and you should try
Dave Airlie wrote:
This takes some of the stuff that was recently submitted to the
xfree86.org for the i830 and tries to move the i810 along similiar
lines...
is all cosmetic apart from a new define for the FRONTBUFFER command this
is what they call it in the i815 spec anyways.
I'm submitting th
Dave Airlie wrote:
Which application is this?
my own internal application (it doesn't do much just some quad texture
mapping (About 20 quads on screen).
Would it be possible to see the source? If not, can you make a little demo
that does something similar and has the same problems that yo
63 matches
Mail list logo
