Vladimir Dergachev wrote:
You could also try FlightGear as far as games go.
Yep, this had been proven to trigger even the obscurest bug during the
emergence of the r200 driver ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Hello,
Adam K Kirchhoff wrote:
These are the games I've tried with the latest CVS from this afternoon:
[...]
Frankly, I'm thrilled at the handful of games that are now working!
Those who are looking for additional stress-test cases for OpenGL-
(especially R300-, I don't have one myself)
Vladimir Dergachev wrote:
What could work, however, is to make a *board* that is capable of decent
3d. Put lots of memory, lots of bandwidth and several DSP to approximate
the same level of raw floating-point power as 3d GPUs. Leave everything
else to the software.
This reminds me of TIGA
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices (like Solaris or
Martin Spott wrote:
Alex Deucher wrote:
I don't know about that. I can forsee IGP becoming _the_ standard
method for video. Look at sgi... all of their video systems use
system memory, [...]
Really ? Which one ?
I know the O2 does, but MGRAS and VPro ? I'm not absolutely sure
Alex Deucher wrote:
I don't know about that. I can forsee IGP becoming _the_ standard
method for video. Look at sgi... all of their video systems use
system memory, [...]
Really ? Which one ?
I know the O2 does, but MGRAS and VPro ? I'm not absolutely sure
but I assume they have
Alex Deucher wrote:
--- Martin Spott [EMAIL PROTECTED] wrote:
Really ? Which one ?
I know the O2 does, but MGRAS and VPro ? I'm not absolutely sure
but I assume they have memory on their respective graphic boards, at
least they have texture memory,
I though they used system ram
Ian Romanick [EMAIL PROTECTED] wrote:
3. After some testing and cool down period, merge the branch into the
trunk. I expect this to happen fairly quickly.
In-progress. Please test this branch! :)
Would I notice any difference on a non-r200 card or do your changes
affect r200 only ?
Ian Romanick [EMAIL PROTECTED] wrote:
It looks like I should be able to convert the MGA driver today, but I
can't make any guarantees.
I'd prefer the 'radeon' driver, because I gave my r200 card to my
friend ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its
David D. Hagood [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
It would be annoying for people with dialup connections if make required
access to a remote CVS repository.
And how would that be any different than syncing up with the main DRI
CVS repo? If you are building one from CVS, you
Ville Syrj?l? [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote:
there's also this driver:
http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/
I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP...
AFAIK G450 PCI cards have an
Alex Deucher [EMAIL PROTECTED] wrote:
I can switch back to the old order in the mean time, however, I'm not
sure if it is any more or less reliable than the current code. both
work fine on my hardware.
I just rebuilt the stuff with a CVS checkout from one hour before now.
When I do _not_
On Thu, Oct 16, 2003 at 06:30:53AM -0700, Alex Deucher wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
I'll ask him - he moved to southern Germany earlier this year,
Martin.
--
Unix _IS_ user friendly - it's just selective
Alex Deucher [EMAIL PROTECTED] wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Sorry, currently he's forced to finish his dissertation. He says you
might have to wait at least a month until he'll be able to deal with
that,
Martin.
--
Alex Deucher [EMAIL PROTECTED] wrote:
I just committed a major rework of mergedfb to CVS. almost all of the
code is now in radeon_mergedfb.c/h. I also committed Hui's latest code
drop from xfree86 CVS. Let me know if anyone has any problems.
I'm fine with running the 'new' X server _modules_
Chris Ison [EMAIL PROTECTED] wrote:
--Boundary_(ID_KcARw6HFWym7RIWbxkMyIg)
Content-type: text/plain
Content-transfer-encoding: 7BIT
can someome please tell me whats causing the video corruption in the
attached png image, and explain how to fix it.
I'd say the main bug is _YOU_ posting a
On Mon, Oct 13, 2003 at 06:56:32AM -0700, Alex Deucher wrote:
Can you clarify what you tried and what the problem is?
When I restart the 'new' (with MergedFB) XFree86 X server binary with
the old XF86Config (attached) I get a flickering screen with a
resolution that is obviously below what I
Jos? Fonseca [EMAIL PROTECTED] wrote:
Anyway, I'm now building a snapshot. If it succeeds please do a public
request for testing on the dri-users and dri-devel.
probably combined with a short list of common pitfalls ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who
I just did a small test with FlightGear against the recent CVS checkout
from freedesktop and I'm delighted. Everything works as expected,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Martin Spott [EMAIL PROTECTED] wrote:
I just did a small test with FlightGear against the recent CVS checkout
from freedesktop and I'm delighted. Everything works as expected,
I forgot to mention, that I'm running stock DRM kernel modules
from Linux-2.6.0-test5 (Radeon7500),
Martin
Alan Hourihane [EMAIL PROTECTED] wrote:
But I also tagged it before starting, so if someone wants to branch for
a stable tree you can do it off the trunk-20030912 tag.
Did this already happen on 'freedesktop.org' or still on SF ?
Martin.
--
Unix _IS_ user friendly - it's just selective
Eric Anholt [EMAIL PROTECTED] wrote:
If anyone wants to test, [...]
Which video card would you recommend for trying ? I'd see if I can get
one,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Keith Whitwell [EMAIL PROTECTED] wrote:
Martin Spott wrote:
I'm running a quite up-to-date mirror in Germany - currently without public
access, but we could change this. Though this mirror suffers from absence of
the SF server too
What sort of a mirror, Martin?
I did a daily CVS
Larry McVoy [EMAIL PROTECTED] wrote:
On Wed, Sep 03, 2003 at 02:17:19PM +0100, Alan Cox wrote:
On Maw, 2003-09-02 at 19:42, Jon Smirl wrote:
There are 31 people with write access to dri.sf.net. The simplest solution
would be for those 31 to switch to BitKeeper.
If thos 31 are OK with that
Larry McVoy [EMAIL PROTECTED] wrote:
People claim that our license is a problem but the only real problem is
the people making the noise. [...]
Things are getting ridiculous when you start to superimpose your attitude
towards ethics on others - especially when you are obviously lacking the
Chris Ison [EMAIL PROTECTED] wrote:
DRI is still quite young and alot of people still have the Screw you
Billy Goat attitude, [...]
Please remember that DRI is not Linux,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Thomas Emmel [EMAIL PROTECTED] wrote:
and this message means that the CVS-server is full.
I think this was mentioned before two days ago.
Some days before I had the problem that the download hangs in
xc/xc/util/patch infinitely. Now I tried to download completely
from scratch without
Martin Spott [EMAIL PROTECTED] wrote:
Ian Romanick [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by: [EMAIL PROTECTED] 03/08/08 13:34:08
Log message:
Removed the R{ADEON,200}_AGP_TEX_OFFSET
Ian Romanick [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by: [EMAIL PROTECTED] 03/08/08 13:34:08
Log message:
Removed the R{ADEON,200}_AGP_TEX_OFFSET contant as it's not really a
Michel Daenzer [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/07/29 03:11:48
Log message:
* IRQ code cleanup suggested by Linus Torvalds
* i830
Currently I don't know _what_ has been changed because ATM I don't have
access to the mailing list. But there _must_ have been substantial changes
because apparently the too dark lightning with TCL on Radeon bug has been
fixed. Running FlightGear on a Radeon9100 with the R200 driver I can't
tell
Martin Zimmermann [EMAIL PROTECTED] wrote:
Maybe we can collect a list of all known and maybe tested mirror pages ...
and repost on [EMAIL PROTECTED]
1. rsync -avz --delete rsync://mefriss1.swan.ac.uk/dri/HEAD/ HEAD/
2.
I'm currently trying to collect experience on how reliable I can
Rupert Levene [EMAIL PROTECTED] wrote:
On Thu, Jul 03, 2003 at 01:07:28AM +0200, Michel Dänzer wrote:
PS: http://levene.dyndns.org/invisible-text/normal.png does show a
driver problem - the lighting is wrong with HW TCL - but you didn't
report that... ;)
Well I'd assumed that _this_ was a
Jos? Fonseca [EMAIL PROTECTED] wrote:
If not then the solution would imply moving the CVS repository to a new
machine, but where would that be? XFree86.org? Some SF look-a-like?
As far as I know BerliOS is hosting quite a few OpenSource projects. This is
intended to be some SF alternative. I
Zik Saleeba [EMAIL PROTECTED] wrote:
Running the Torque Engine example application
(http://www.garagegames.com/) runs for a few frames and then locks the
system up. X is completely hung and it can't be killed. Remote logins
to the machine are possible but the display is frozen until reboot.
Hello Jose (I don't know how to type the accent on my keyboard),
On Sun, Jun 15, 2003 at 09:21:18PM +0200, Martin Spott wrote:
I'll redo the debug output on monday - just to make shure I did not make any
mistake. I'm doing this with an OEM Radeon9100. Unfortunately I gave away my
Radeon7500
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote:
And everything else looks normal - the AGP seems to be alive and
kicking. Do you still get direct rendering: No in glxinfo or AGP not
available in /var/log/messages ?
Yep:
1.) /var/log/XFree86.0.log tells me
(II) RADEON(0): [drm]
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote:
And everything else looks normal - the AGP seems to be alive and
kicking. Do you still get direct rendering: No in glxinfo or AGP not
available in /var/log/messages ?
As I already said: Yes.
Now I rebuilt the kernel modules from
On Mon, Jun 16, 2003 at 02:31:45PM +0100, José Fonseca wrote:
On Mon, Jun 16, 2003 at 01:48:35PM +0200, Martin Spott wrote:
(II) RADEON(0): Direct rendering disabled
This can't be. This log can't possible match the other one you gave me.
In the /var/log/messages it showed the agp buffer
On Mon, Jun 16, 2003 at 03:47:10PM +0200, Martin Spott wrote:
I've attached the DRM patch I'm talking about the whole time. You might
compare it with yours to see, if my CVS tree is missing some part. The patch
applies against stock 2.4.20 kernel DRM.
Stupid - sorry for my mistake. This does
Roland Scheidegger [EMAIL PROTECTED] wrote:
FWIW, I get that now always when I start the X server, then shut down
the X server and start it again. DRI will never work again, unless I
rmmod the radeon module manually before I restart the X server. Sounds
like some initialization thing.
On Sun, Jun 15, 2003 at 07:47:35PM +0100, José Fonseca wrote:
Something fishy is going on here. My debug statements never appear in
your log and I've just retested on my test box with the latest CVS and
everything works as expected with the radeon driver:
[...]
Martin, are you're sure you're
Content-Disposition: attachment; filename=drm_agp-debug2.diff
I applied both of Jose's patches and loaded the 'radeon' module with
drm_opts=debug as suggested my Michel. I attached the compressed debug
output from loading the module until X server startup that I found in
/var/log/messages.
If
Martin Spott [EMAIL PROTECTED] wrote:
I applied both of Jose's patches and loaded the 'radeon' module with
drm_opts=debug as suggested my Michel. I attached the compressed debug
output from loading the module until X server startup that I found in
/var/log/messages.
BTW, I forgot to mention
Hello Jose,
Since it's easy for you to rebuild the kernel module, try the attached
patch which adds a debug output line. That line should appear, and both
pointers should be non-NULL.
I applied your patch but I did not notice where the expected debug output
should appear. Should it show up on
On Thu, Jun 12, 2003 at 12:19:17PM +0200, Michel Dänzer wrote:
On Thu, 2003-06-12 at 08:42, Martin Spott wrote:
I applied your patch but I did not notice where the expected debug output
should appear. Should it show up on STDERR, in the syslog, in XFree ?
Wherever kernel output goes
Jose Fonseca [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/
Changes by: [EMAIL PROTECTED] 03/06/03 16:27:02
Log message:
Split declarations/definitions in drm_scatter.h into
Matt Sealey [EMAIL PROTECTED] wrote:
I'm sure that MPlayer or Xine actually support an OpenGL output
plugin already. Chances are it's Xine, but I haven't touched it in
6 months, maybe they removed it?
I believe it's still there. Before propagating the use of 'new' API's in
Xinre for
Matt Sealey [EMAIL PROTECTED] wrote:
I'm sure that MPlayer or Xine actually support an OpenGL output
plugin already. Chances are it's Xine, but I haven't touched it in
6 months, maybe they removed it?
I believe it's still there. Before propagating the use of 'new' API's in
Xinre for example
Jos? Fonseca [EMAIL PROTECTED] wrote:
FYI these snapshots were built by checking out the DRI CVS over the
XFree86 4.3.0 source [...]
This is tough - I didn't think it would work :-)
This remembers me of a question that came up recently: Some of the changes
that recently were made to the
On Fri, Apr 04, 2003 at 03:59:16PM +0200, Michel Dänzer wrote:
On Fre, 2003-04-04 at 14:56, Martin Spott wrote:
This remembers me of a question that came up recently: Some of the changes
that recently were made to the XFree86 CVS repository touch files that are
part of the DRI tree. Does
Martin Spott [EMAIL PROTECTED] wrote:
Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to freeze the texmem-0-0-1 branch and begin the arduous task of
merging the trunk. Since I'm not quite as experienced at doing merges
as Alan, it will probably take me awhile...
It is probably not bad
I'd like to express my thanks for the merge of XFree86-4.3 and the related
work.
The current 'trunk' is the most stable and accurate implementation of hw-
accelerated OpenGL I've seen on Linux with a Radeon (in my case) for quite
some time (as long as you factor out the light position issues with
Ian Romanick [EMAIL PROTECTED] wrote:
Since it appears that the filp work has been merged in to the trunk, [...]
Oh, I noticed too late
I'm going to freeze the texmem-0-0-1 branch and begin the arduous task of
merging the trunk. Since I'm not quite as experienced at doing merges
as
Louis Garcia [EMAIL PROTECTED] wrote:
Is their anyway I can get a diff for XFree86-4.3 DRI against 2.5.latest?
I'm starting to play with this kernel and want dri working for my
radeon.
Diff against what ? XFree86-4.3.0 should work fine 'out of the box' with
Linux-2.5.x. I've already tried that
Jens Owen [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Alan Hourihane wrote:
I'm going to start the 4.3.0 merge. Be prepared for breakage.
I'll post another followup when I'm finished.
Thanks for doing this, Alan.
Definitely. Thanks, Alan.
Oh yes, this way we'll have best of both
Keith Whitwell [EMAIL PROTECTED] wrote:
It's always a shock to see that what is meant to tease when written comes out
looking more like a direct attack when read back...
Oh, I would agree even if it was considered as sort of an attack,
Martin.
--
Unix _IS_ user friendly - it's just
Philip Brown [EMAIL PROTECTED] wrote:
Perhaps then, this will provide enough incentive for DRI to move back into
a pure extension module form, rather than its current xfree tree
entanglement.
You don't want to imply that people touch bigger areas as is would be
necessary for DRI development -
Michel D?nzer [EMAIL PROTECTED] wrote:
The texmem branch doesn't have the FlushVertices fix yet, which seems to
help with a number of lockups. Try
http://penguinppc.org/~daenzer/DRI/applied/r200-radeon-flushvertices.diff
If it does not work, try this one - I never experienced any
On Mon, Mar 17, 2003 at 02:41:43PM +0100, Michel Dänzer wrote:
On Mon, 2003-03-17 at 14:11, Martin Spott wrote:
Michel D?nzer [EMAIL PROTECTED] wrote:
Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45
Log message:
Fix recycle lockup (Michel Danzer)
Modified files
Michel D?nzer [EMAIL PROTECTED] wrote:
You could try to set the environment variables RADEON_NO_CODEGEN,
RADEON_NO_VTXFMT and RADEON_TCL_FORCE_DISABLE [...]
BTW, I just aquired a Radeon9100 clone to see if serveral 'features'
resemble the
Michel D?nzer [EMAIL PROTECTED] wrote:
BTW, are you actually using 4x transfer rate? If so, have you tried
lowering it?
I't like to note that the lockups I saw with FlightGear and Solace were
completely independent from the AGP transfer rate of my Radeon7500. I did
quite a few tests to be
Martin Spott [EMAIL PROTECTED] wrote:
Keith Whitwell [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45
Log message:
Fix recycle lockup (Michel Danzer
Keith Whitwell [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45
Log message:
Fix recycle lockup (Michel Danzer)
Modified files:
Michel Daenzer [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35
Log message:
Set Mesa hooks to flush vertices on state changes (Keith Whitwell)
Whps, it appears
Martin Spott [EMAIL PROTECTED] wrote:
Michel Daenzer [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35
Log message:
Set Mesa hooks to flush vertices on state changes
Philip Brown [EMAIL PROTECTED] wrote:
On Sun, Mar 02, 2003 at 10:33:15PM +, Martin Spott wrote:
I don't know _why_ this works
because you're not using DRI.
DRI essentially for Xserver-side stuff. The X server is on the SGI.
That's quite clear ;-)
DRI is not involved here. You're just
Hello, did you know that remote display of OpenGL apps is partially
functional with DRI ? At least the client side works ! I'm currently running
FlightGear on a Linux PC against an SGI Octane functioning as X terminal.
Performance is not bad - at least better than running FlightGear native on
the
Mike A. Harris [EMAIL PROTECTED] wrote:
On Sat, 1 Mar 2003, Smitty wrote:
Which is probably why Molton is trying to instigate a divorce
from Glide for the V3.
I certainly support that move. Anholt was working on Glide3
recently a bit as well. I dunno how far he got, but I've been
meaning
Nick Kurshev [EMAIL PROTECTED] wrote:
Image distortion became visible in oct 2002.
This probably was the time when hardware-TCL came into play !?
You could try to set $RADEON_TCL_FORCE_DISABLE to 't' and see if it makes
any difference,
Martin.
--
Unix _IS_ user friendly - it's just selective
Michel D?nzer [EMAIL PROTECTED] wrote:
The radeon driver uses the DRM for 2D acceleration when DRI is enabled,
Is the radeon driver the only one doing so ? Is it possible that heavy
simultaneous use of 2D and 3D graphics is responsible for the DRM freezing
the X server with FlightGear ? You
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
Alan Cox [EMAIL PROTECTED] wrote:
I updated the radeon DRM to include the texture upload changes. My
radeon hang with flightgear now happens every two hours instead of
instantly.
Would you please be so kind to try the B747 ? Please run FG with the option:
--aircraft=747-yasim
When it dies X
Felix K?hling [EMAIL PROTECTED] wrote:
No idea, just a comment. This reminded me of the famous X hangs when
flightgear exits. Recently I read in some posts on the plib-users
mailing list that flightgear is multi-threaded, too. The situation is
somewhat different, though. There is only one
Alan Cox [EMAIL PROTECTED] wrote:
With a 747 it starts up, I get a cockpit, I turn up the engines taxi down
the runway and embed the nose in the ground. I can't fly a 747 but I don't
see the problem you reported
Thanks for the test. Maybe we have too look at the differences between a
On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote:
On Fri, 2003-02-14 at 14:52, Martin Spott wrote:
Where did you take the DRM sources from ? I usually take the source for the
DRM module from the same DRI CVS tree I use to build the whole DRI thing,
Mike Harris builds in Red Hat
How can get a new module? Do I have to build XF86 from source
No, you don't have to rebuild the whole XFree86. I usually take the Sources
from:
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/
xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/
and adjust the Makefile
On Tue, Feb 18, 2003 at 02:34:29PM -0500, Leif Delgass wrote:
On Tue, 18 Feb 2003, Martin Spott wrote:
So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ?
I noticed that Michel's fix for large textures in
radeon_cp_dispatch_texture() has only been in XFree86 cvs since
I wrote that MindRover crashes X with Radeon VE and DRI. Last days I asked few
people on irc to test MindRover-demo with their Radeons (TCL and no-TCL, DRI
from current CVS and older). All of them got X locked. [...]
I'm glad to see that FlightGear is not the only reliable test case for the
[... Alan Cox wrote ...]
On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote:
That DRM is pretty old, is the 3D driver from the same date? Someone
said on an XFree86 list that the flightgear lockups went away for him
with XFree86 4.3.0rc1.
My lockup with flightgear on the 9000 with 4.2.99 based
On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote:
On Fri, 2003-02-14 at 14:52, Martin Spott wrote:
My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent
DRM module.
Where did you take the DRM sources from ? I usually take the source for the
DRM module
Can someone commit this? Does this fix *all* the problems? I don't know if
it would.
It probably fixes SW TCL bugs - as Felix states - but it does not touch the
HW TCL related problems with the radeon driver. They still exist,
Martin.
--
Unix _IS_ user friendly - it's just selective about
On Thu, Feb 13, 2003 at 04:12:46PM +0100, Felix Kühling wrote:
On Thu, 13 Feb 2003 15:29:44 +0100 (CET)
Martin Spott [EMAIL PROTECTED] wrote:
It probably fixes SW TCL bugs - as Felix states - but it does not touch the
HW TCL related problems with the radeon driver. They still exist
[...] Since the GATOS head is now based
on current XFree86 cvs, I may not have a new patch until 4.3.0 is released
and changes get propagated back to the DRI and GATOS trees.
Could anyone tell me if I'll find recent GATOS stuff merged into the current
XFree86-4.3 pre-releases ? I did not find
There are now two patches, one from Egbert Eich (who reported the problem). I
haven't had time to look at his as it changes some deep, dark, dri stuff that
I wasn't ever involved with, but looks sane nonetheless. His avoids the error
reply from the X server, whereas mine copes with it
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ).
Where do I find at least a short explanation on the effect this patch should
show to me (to the user) ? The only
That would be easy enough to verify with oprofile. Just take a profile
with and without the patch. In order to get profile data on the GL
driver, do this:
oprofpp -l /usr/X11R6/lib/modules/dri/radeon_dri.so
Thanks for the explanation.
If there's anything else I can do to support your
[...] The notion that users dont edit
config files by hand may be all fine and good in the microsoft world but
last time I checked I was using linux. You can't make the same
assumptions about what users want to do as you can in the microsoft
world.
I'd like to add _strong_ support to
[ Ian wrote ]
There have been rumblings on [EMAIL PROTECTED] about problems with
Radeon in 4.2.99.4, but I didn't think that those problems had
propogated into DRI CVS yet. That's a shame. :(
I think it's the other way round: The DRI stuff that got merged into XFree86
4.2.99.x 'releases'
On Tue, Jan 07, 2003 at 03:40:09PM +0100, Martin Spott wrote:
http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png
[...]
Wow, that's a really cool failure mode... What's your GL_draw_method (in
~/.Solace/registry) set to? Try changing it to 1 or 0...
Yep, this circumvences
On Tue, Jan 07, 2003 at 03:48:51PM +0100, Martin Spott wrote:
[...]
It was like the image that was supposed to be clipped because it was
hidden became visible briefly as the light went by. It just happens
briefly and then it is quickly corrected. This is probably not an
accurate
: text/plain; charset=us-ascii
On Fri, Dec 20, 2002 at 12:47:34PM +0100, 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
http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png
Did you know that 'Solace' - recently mentioned on this list - also shows
this sort of artifacts ?
And I can guarantee it's not a bug in Solace. ;)
http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png
Yes, that would be the one. If you take all the torus together it reminds
me of a cartoonish framework for what could be overall a sphere. Imagine
stretching a piece of cloth around the whole grouping ...
Also, what do you mean by flickers?
It was like the image that was supposed to
Oops - mistype. Switching the GL_draw method to 0 correct all of the
anomalies I was seeing in the display.
That makes more sense. :) Sounds like it's a problem with displaylists and
vertex arrays. Does it still happen if you set the value of GL_dlistMax to
0?
This not only cures
Also, if whoever it was who posted that screenshot could change the Solace
setting of GL_draw_method to 0 (which switches to immediate mode rendering
rather than using vertex arrays) and see if that continues with the
funkiness, that would be another useful data point. :)
I should step in
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
Did you know that 'Solace' - recently mentioned on this list - also
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
On Fri, Dec 06, 2002 at 04:29:14PM +0100, Michel Dänzer wrote:
So apparently the problem stems from the interaction between 3D and 2D,
e.g. missing synchronization, locking problems, indirect buffer issues,
This is my impression.
I did another run, I did a local login via xdm and killed
I just ran FlightGear with this branch (instead of employing binary
snapshots) on my Radeon7500. Everything is quite fast, the colours look
perfect, the previously known feature of everything appearing too dark has
gone !
Hmmm, today I had to realize that this is still dependend on the
1 - 100 of 129 matches
Mail list logo
