Stephane Marchesin wrote:
Philipp Klaus Krause wrote:
Adam K Kirchhoff schrieb:
I'm sure this confirms what are already known issues with the r300
driver, but felt it'd be worth posting anyway. There's definitely
something bizarre going on with textures. They're much crisper with the
khaqq wrote:
On Thu, 8 Dec 2005 22:35:37 -0500
Alex Deucher [EMAIL PROTECTED] wrote:
On 12/8/05, Roland Scheidegger [EMAIL PROTECTED] wrote:
khaqq wrote:
I wonder if different *video* chip revisions could be a factor.
An interesting idea. I've never heard that there were multiple
khaqq wrote:
I wonder if different *video* chip revisions could be a factor.
An interesting idea. I've never heard that there were multiple revisions
of these chips (which made it to retail), though it might be possible.
It should be printed on the gpu itself afaik, or is it possible to get
vehemens wrote:
Posting my latest DRM and Mesa patches in case they should prove useful to
anyone else. They are to head as of early Saturday.
I moved the CP idle outside the while loop in radeon_state.c. I think it may
apply to the R300 as well as there is an if R300 idle command in the
Sergio Monteiro Basto wrote:
Hi Roland,
I am trying testing s3tc with q3demo
adding -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS
but I am getting this error :
Mesa 6.4.1 implementation error: bad S wrap mode in r200SetTexWrap
Please report at bugzilla.freedesktop.org
Mesa 6.4.1
Sergio Monteiro Basto wrote:
Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1
-DHAVE_ALIAS Ian, and those ones are needed ?
Can't comment on the others (though usually care must be taken with
the threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=1
will obviously cause it to
Felix Kühling wrote:
Whats the point of doing these operations in DRM anyway?
Personally I would just pull out as much code from there as possible.
I was wondering about that too. There may be some reason for doing
those things in the kernel, but I don't know of any.
At least on some
Sergio Monteiro Basto wrote:
After analyze how build Mesa from CVS with make linux-x86-dri and
how xorg built same Mesa source with make World.
Ian Romanick has point that Mesa code should have IN_DRI_DRIVER
Define. So, I found on xc/lib/GL/mesa all subdirs: shader swrast tnl
x86 main math
Dave Airlie wrote:
Hi Roland,
Just to reconfirm what I said on IRC, I put my M7 back into my
machine and my internal application is defintely broken with the latest
radeon texrect changes...
I'll leave the M7 in for a few days and I'll have a look at the code if I
get a chance..
Does
Michel Dänzer wrote:
On Wed, 2005-10-12 at 11:01 +0100, pedro.lixo wrote:
By the way, if i do the override that won't do nothing, in terms of
amount of memory visible to GPU, right?
No, it will only affect what the driver thinks, and if that doesn't
correspond with what's actually there
Luis Felipe Strano Moraes wrote:
Hello,
just sending this to describe my experience so far with
the open-source r300 drivers. My card is a Radeon 9600Pro
with 256 mb ram by Gecube.
After installing everything following this tutorial :
Alexander Toresson wrote:
I'm trying to get the r300 drivers to work on a laptop with an ati
radeon mobility x300. The laptop is running debian etch. This is what
I've done:
1. Installed binaries of Xorg 6.9rc0 from experimental. 2. Installed
binaries of libgl1-mesa-dri 6.3.2 from unstable
Philipp Klaus Krause wrote:
In that sense, I'd consider NV_vertex_program as bloat just as well.
Applications really always can deal with not available non-standard
extensions very well.
About GL_NV_vertex_program:
1) It was the first nice vertex program interface and is used in many
old
Philipp Klaus Krause wrote:
Since vertex program support was the main point of the patch, and the
discussion has shown reasons not to add any vertex program support to
the r128 I think that my patch should be ignored. I might create
another one once Mesa implements vertex shaders.
Well the
Philipp Klaus Krause wrote:
Roland found out how to do bigger aliased points on r200 hardware a long
time ago. AFAIK the patch was never applied since people failed to see
it's importance.
3D modellers use points to mark the currently selected vertices. A
maximum point size of 1 means they are
Jason Cook wrote:
I do appologize if I'm cross posting here. I'm not sure which forum
would be best to address this. I have a encountered an error when
running xscreensaver-demo as a normal user. In Slackware 10.2 the
daemon is not running by default and there is a popup window that
promts to
Philipp Klaus Krause wrote:
Roland found out how to do bigger aliased points on r200 hardware a long
time ago. AFAIK the patch was never applied since people failed to see
it's importance.
3D modellers use points to mark the currently selected vertices. A
maximum point size of 1 means they are
Bernardo Innocenti wrote:
Vladimir Dergachev wrote:
By the way, quake3 (original version) doesn't work any more with
latest Mesa + DRM on both r200 and r300. It just hangs immediately
after entering a map.
Have you tried disabling some graphics options ? I just run Quake3
on somewhat old
Michel Dänzer wrote:
On Wed, 2005-09-07 at 01:52 +0200, Roland Scheidegger wrote:
Support for ATI_fs will be enabled automatically if texture_units is set
to 6 (there is simply no useful way to expose this with less units).
Are these really related? My understanding is that texture_units
Roland Scheidegger wrote:
Michel Dänzer wrote:
On Wed, 2005-09-07 at 01:52 +0200, Roland Scheidegger wrote:
Support for ATI_fs will be enabled automatically if texture_units is
set to 6 (there is simply no useful way to expose this with less units).
Are these really related? My
Roland Scheidegger wrote:
A quick view what's working and what isn't:
A simple hacked up multiarb demo using ati_fs instead works. Even
changed so it does a dependant texture read it still looks like the same
as with fglrx. OTOH, a demo named t3 (have forgotten where I've found
it) doesn't
Ian Romanick wrote:
Another good test would be to modify progs/demos/pixeltexl to use
ATI_fs instead of SGIS_pixel_texture.
Sounds actually not that easy. Or maybe I just don't understand the spec
there very well.
Does t3 work with swrast?
With the version in cvs, no. With my version, yes
I made some progress getting ATI_fragment_shader to work, so I've
uploaded some patches:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/r200_fragshader.c
http://homepage.hispeed.ch/rscheidegger/dri_experimental/ati_fs_drm.diff
Brian Paul wrote:
Just broken output as before. No assertion failure. Actually, you can
guess the output somewhat, it's just tiled.
OK, I think I've fixed that now. I'll remove the assertion.
Yes, works now. Wouldn't the radeon need that change too? Strange that
it would be different
Brian Paul wrote:
I'm checking in the updated radeon and r200 drivers and I'll do the
mach64 and r128 drivers next. I've tested the radeon changes, but not
the r200. If someone could run the reflect demo on r200 and use the
a/s/d/f/c keys to exercise the span routines, that would be good.
Brian Paul wrote:
I'm checking in the updated radeon and r200 drivers and I'll do the
mach64 and r128 drivers next. I've tested the radeon changes, but not
the r200. If someone could run the reflect demo on r200 and use the
a/s/d/f/c keys to exercise the span routines, that would be good.
Brian Paul wrote:
- Pageflipping is completely broken. Looks like stuff gets drawn to
the right place only every second frame or something like that (i.e.
heavy flicker).
What's the trick for enabling/testing page flipping? I thought I had it
going with the radeon, but I guess not.
Option
Brian Paul wrote:
Option EnablePageFlip true
somewhere in the xorg.conf device section. It is still problematic
though, just yesterday I've noticed that detection if it has to be
disabled is pretty broken now (e.g. starting two opengl apps it seemed
to miss to disable it 3 out of 4 times :-(.
Aapo Tahkola wrote:
That check doesnt currently seem to work because some setup(at
preinit) with color tiling enabled will get done earlier.
Does this version break r200s or radeons?
From the top of my head, I think it does. For certain 16bit resolutions,
that is (as the resolution won't be a
I've looked at that crossbar patch for r200 again and improved it a bit.
It will now
- disable texture sampling of units if the result is not used
- reorder tex env instructions to be always in-order on the gpu
(according to earlier tests, this can make a performance difference,
Philip Armstrong wrote:
On Thu, Aug 25, 2005 at 12:35:56PM +0100, Philip Armstrong wrote:
On Thu, Aug 25, 2005 at 01:36:41AM -0500, Alan Grimes wrote:
PPRACER: Works but has nasty texture bug affecting the ground textures..
(Problem disappears when I run it on the other, unaccelerated
Adam Jackson wrote:
On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote:
What are the minimum requirements of Xegl in terms of extensions
supported?
Not much. See http://freedesktop.org/wiki/Software/Xgl, but the
major requirements are:
NV_texture_rectangle ARB_texture_border_clamp
Adam K Kirchhoff wrote:
Thanks for the tip. I updated to not only the latest Mesa cvs and
drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4
works with DRI enabled. But... glxgears segfaults:
(gdb) run
Starting program: /usr/X11R6/bin/glxgears
[Thread debugging using
Sergio wrote:
Definetively not ? However, i don't readed this in the several .def and
.cf files of the checkout. And :
1) my new CVS radeon_drv.so contains effectively a lot of AGP, r200, and
DRI features, and i compiled (with your useful help !) it really on
Solaris 10, with Makefiles which
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
In addition to my recent commit to Mesa CVS, try this patch. I have
verified that everything builds and that glxgears works on a system with
current X.org CVS installed.
This patch *should* fix
(sorry for the previous message, wasn't meant to be sent...)
Ian Romanick wrote:
This patch *should* fix everything. :) I built it on a system
*without* X.org 7.0rc0 on it, so there may still be build problems on
those systems. Dunno.
Works for me on r200 (built on latest xorg cvs).
Ian Romanick wrote (in the GL_ARB_texture_env_crossbar on r200 thread):
Other optimizations are possible, but I never explored them. Most of
the ones that I could think of are probably unlikely in practice.
Doing things like replacing {T1 + T2}, {P + P}, {P + T3} with {T1 +
T2}*2, {P + T3},
Ian Romanick wrote:
I'm really, really confused as to why this bug doesn't hit X.org CVS
builds. The only way that it would not hit is if IN_DRI_DRIVER isn't
set. If that's the case, it's also a bug. I'm not sure if we should
just apply this patch (should just need the changes to dispatch.h)
Applications which use display lists are broken for me on r200. Below is
the debug output for glxgears, which obviously doesn't really want to
call glGenerateMipmap... (it displays completely black, on the upside
though framerate is high :-)). Not sure what caused it, happens with
both
Matthias Hopf wrote:
On Jul 28, 05 11:52:10 +0200, Wladimir van der Laan wrote:
This is the sound of me hating ATI for making such useless pixel
shaders.
R200 did not really have pixel shaders. They had a configurable pixel
pipeline, that's different. Comparable to GeForce2, a little bit
Juhana Sadeharju wrote:
Hello. I found a reason why ATI nor NVIDIA provides us hardware
details:
http://www.futuremark.com/companyinfo/3dmark03_audit_report.pdf
Regarding ATI: This performance drop is almost entirely due to 8.2%
difference in the game test 4 result, which means that the test
Alan Grimes wrote:
Software rendering: WORKS (about 1.2 fps, if that..)
ATI Mach 64 (PCI): WORKS -- minor image degradation as would be
expected of a card of that vintage... (around 5 fps...)
ATI Rage 128: Works, slows down dramaticly in some areas, has a number
of visual artifacts.
Patrick McFarland wrote:
On Wednesday 27 July 2005 02:43 pm, Roland Scheidegger wrote:
Juhana Sadeharju wrote:
Please continue developing reverse-engineered, open sourced drivers.
As time permits...
Heh, the only thing I want is GL ARB fragment shaders accelerated as much as
possible
Patrick McFarland wrote:
On Wednesday 27 July 2005 04:54 pm, Ian Romanick wrote:
Patrick McFarland wrote:
Even if we violate precision/range stuff, being able to accelerate
simplistic shaders would be quite useful. Its better than not having a
software implementation of the shader pipeline.
Aapo Tahkola wrote:
That's true, but to avoid the huge drops you could also just decrease
texture detail. Or implement the second texture heap in main memory and
use gart texturing (though you'd also need to manually increase the gart
size). There are some problems with that for r200, and the
Bellido Nicolas wrote:
Hi all,
I have a Radeon 9800Pro that I'm trying to get working with the R300 tree on
my Gentoo box.
I'm running a 2.6.12-gentoo-r4 kernel with the X11 6.8.99.15 ebuild.
As I saw a post recently on the dri-devel list, I built DRI and Mesa from CVS.
When the radeon
Ian Romanick wrote:
I'm actually wondering how ATI solved that problem in their driver,
I couldn't see an easy way out to avoid the fallback - even using
the 2 additional tex env stages or the second phase of the
fragment pipeline isn't going to fix the issue I think. Maybe
someone else has a
Roland Scheidegger wrote:
but you can have 6 reads per stage (thanks to different alpha/rgb
sources), e.g. the whole register set.
Ah scratch that, wrote too fast. This if of course not an issue, since
you can address the alpha and rgb regs separately too. I just didn't do
it due to the added
Tino Keitel wrote:
On Fri, Jul 15, 2005 at 10:08:44 +0200, Tino Keitel wrote:
On Fri, Jul 15, 2005 at 09:50:42 +0200, Tino Keitel wrote:
Hi folks,
when the Xorg server is started, my machine will freeze completely if
radeon.ko is loaded. I can not log into it via SSH, and I also don't
see
Dave Airlie wrote:
Okay I know the radeon has a slightly wierd 0..1 instead of 0..[wh],
why does this cause a fallback to non-tcl? can the hardware not do it or
are we missing something in Mesa to let it ...
How else would you do the coordinate translation if not with a tcl
fallback? I think
Aric Cyr wrote:
I had originally posted this on the xorg-devel mailing list, but didn't get
much response, so thought I'd try my luck here...
I was just wondering if there was any progress or planned work to
update the server's GLX implementation to 1.3.? It looks like about
half of the work
Hamish Marson wrote:
Fixed it.
Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an
r300 problem. I changed the xorg.conf set
Option EnablePageFlip on # [bool]
to
Option EnablePageFlip off # [bool]
and the flickering went away...
Peter Zubaj wrote:
Hi,
For display corruption when switching from fglrx to radeon driver are
responsible RADEON_SURFACEx_ register.
One question: for what are these surfaces good ?
For tiling, if you read/write directly to the graphic card memory.
Should be no issue with xorg cvs
Ben Skeggs wrote:
S3TC does seem to be the killer for UT2004. I started porting over the
S3TC stuff from the r200 driver a while
back, but haven't had a lot of time recently to fix a couple of issues
with it. Overall fps doesn't seem to take a
huge gain, but the sudden drops to 1-2fps in
Dieter Ntzel wrote:
progs/tests ./texwrap
Texture Border Size = 1
Speicherschutzverletzung (core dumped)
This is still #2516 (rasterization fallbacks cause segfaults), though
the backtrace output has slightly changed due to changes to the t_vertex
code.
Roland
Keith Whitwell wrote:
[EMAIL PROTECTED] wrote:
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=2516
[EMAIL PROTECTED] changed:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
Michel Dnzer wrote:
On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote:
Hi,
One more for good messure.
2048x2048 texturer are corrupted. half (1024x2048) is correct, the
rest is random data from memory
Rune Petersen wrote:
Michel Dnzer wrote:
On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote:
Hi,
One more for good messure.
2048x2048 texturer are corrupted. half (1024x2048) is correct, the
rest is random data from memory.
Not being familiar with the r300 code, I can only guess,
Philipp Klaus Krause wrote:
Well I just tried legends on my system (Debian DRI packages from
nixnuts). I have hardware TCL disabled. legends runs without crashes,
but enabling bumpmapping causes graphics errors on the ground.
Can confirm that. However, with tcl enabled, it neither crashes nor are
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]
In previous reports I found that starting xfree or xorg with dri support
cause a hang after
Helge Hafting wrote:
Since it crashes even without 3d sometimes, the problem does not
seem to be related to dri (as in, dri driver).
Stable as rock, _if_ Load dri is commented out from xorg.conf (or
from XF86Config-4)
Well, commenting that out makes the 2d ddx driver not to use the CP, drm
etc.
Ville Syrjälä wrote:
I think that making the assumption that all memory is preserved when
the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and - things without
repainting the whole screen.
I'm not sure I agree
Michel Dnzer wrote:
I also made it set the source pitch based on the image width. If the
image width is less than 64, we have a problem if the image height is
more than 1 (if the height is 1 the pitch doesn't matter). I made it
return an EINVAL error in that case. I didn't see that case ever
Felix Kühling wrote:
Hi all,
I just uploaded a new DRIconf version (0.2.3), which features better
support for floating-point ranges like the brilinear option proposed
by Roland Scheidegger. There are also a few bug fixes and usability
improvements as well as updates and additions to the README
Paul Mackerras wrote:
+ OUT_RING((texpitch 22) | (offset 10)); +
OUT_RING((texpitch 22) | (tex-offset 10));
Are source and destination pitch always the same?
I found it quite hard to understand what was going on with
tex-width, tex-height and tex-pitch vs. image-width and
Dieter Nützel wrote:
Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger:
Roland Scheidegger wrote: here's a patch which mainly does 3
things: - convert sis, mach64, and radeon to spantmp2. The sis and
mach64 drivers got a slight change, previously you could not read
back alpha values
Michel Dnzer wrote:
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI drivers dated 25 february 2005
Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to spantmp2. The sis and mach64 drivers got a slight
change, previously you could not read back alpha values (always
0xff) and I don't think there was a good reason
Paul Mackerras wrote:
Note that that check is also wrong for ppc64. I think it is going to
be wrong for most 64-bit platforms, since it is assuming that you can
never have ram at a higher physical address than any I/O devices. On
64-bit platforms it is quite common to have some ram and some I/O
Ville Syrjälä wrote:
Like I said before only the RGB components are blended. You can
choose to write 0, 1, As, 1-As, Ad or 1-Ad to the destination
alpha ([EMAIL PROTECTED] register). Currently the
driver seems to write 0. It would probably be a better idea to
write 1 instead.
Sorry, but I just
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you
can see that there are problems with light reflection in those places
where
Dieter Nützel wrote:
You'll even get a newer version, Alan pointed out some subtle issues
with the macro expansion (one of the reasons I don't particularly like
macros...). Instead of fixing all GET_SRC/DST_PTR macros, I got rid of
them too, since they were identical again in all drivers which use
Dieter Ntzel wrote:
Looking a bit at this, this seems to be caused because the number of
pixels to read can be less than zero after CLIPSPAN (don't know if
that's a bug in itself or not).
That was my first thought, too (moving the window out to the left...) ;-)
This is no problem for the generic
Roland Scheidegger wrote:
Here's a one-liner fix, which will cause CLIPSPAN hopefully never return
a negative n1. Seems to work here.
Ian, what do you think? Would it be better to have the optimized
read/write functions deal with negative values instead?
Ah crap those UNLOCK_HARDWARE changes
Dieter Ntzel wrote:
DRM CVS
All texture tiling related patches (drm/dri) have been commited some
weeks ago.
Roland
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
here's a patch which mainly does 3 things:
- convert sis, mach64, and radeon to spantmp2.
The sis and mach64 drivers got a slight change, previously you could not
read back alpha values (always 0xff) and I don't think there was a good
reason for that?
The 3 intel drivers and the s3v are not
Dieter Ntzel wrote:
Am Mittwoch, 16. Februar 2005 21:27 schrieb Dieter Ntzel:
Any change that someone look into this?
Ian, it seems that's related to your new SSE/MMX code.
Thanks,
Dieter
Move window 'out' to the left.
NO sigfault with MESA_NO_SSE and MESA_NO_MMX.
With MMX:
#0 0x406a92b5
Vladimir Dergachev wrote:
By default r300_demo and r300_driver have tiling enabled at 16x16 pixel
squares, in fact the card should come up with this on by default..
Now on to the next question - how can one fix the 2048x2048 limit ?
check out this thread:
Dave Airlie wrote:
2. make ycbcr on r200 dependant on a new chipset flag.. if your chip has a
broken ycbcr (r200 and rv280 look fine so far..) then the flag needs to be
set for it...
I removed support for ycbcr some time ago on everything except r200
based on the assumption that it was just a
Zoltan Boszormenyi wrote:
Hi,
I am running the Linuxconsole.sf.net multiconsole extension on my
machine and I have a Radeon 9200SE/AGP8x and a PCI Radeon7000VE. Both
cards are driven hardware accelerated with DRI.
I noticed behaviour differences running Tuxracer/PPracer between the
two cards.
Hamie wrote:
Hi a..
I just got a Saphire radeon 9600 with 256MB of memory on it. lspci
reports is as two device though, one of which has a pci-id of 4e71,
which I can't find anywhere... Anyone know the details? And which
chipset it is?
This is just the second head. All (or at least all newer)
Marcello Maggioni wrote:
On Thu, 24 Feb 2005 19:07:07 +, Philip Armstrong
[EMAIL PROTECTED] wrote:
On Thu, Feb 24, 2005 at 07:25:15PM +0100, Marcello Maggioni wrote:
I was wondering what's up with the face textures in Doom3 with R200
hardware .
These are as divided in two parts by a black
Marcello Maggioni wrote:
Try running xscreensaver directly.
With XSCREENSAVER alone it effectively runs without problems , but I
wonder why ...
There's a logical explanation for this?? O_o
IIRC the root window isn't double buffered, thus you can't use that in a
useful way for 3D.
Roland
Dave Airlie wrote:
The r200 driver disable ycbcr texturing for non-r200 cards, like my rv280,
however I've just switched it back on and it appears to work for me except
in the case where I've a client side gart texture and using
R200_GART_CLIENT_TEXTURES...
Really? I've just tested this again, and
Since people have asked for it, I decided I'd give it a try...
So here it is, a unified radeon driver (no not r300, only r100 and r200).
http://homepage.hispeed.ch/rscheidegger/dri_experimental/ati_radeon.tar.bz2
exectuable generated will be called radeon_dri.so, for r200 you can just
use a
Dieter Ntzel wrote:
Am Mittwoch, 16. Februar 2005 21:36 schrieb Dieter Ntzel:
Maybe GL_ATI_fragment_shader?
--
- R_InitOpenGL -
dlopen(libGL.so.1)
Open X display
Initializing OpenGL display
Using XFree86-VidModeExtension Version 2.2
DGA DirectVideo
Dieter Ntzel wrote:
This on is SOLVED!
It was due to SuSE's CKRM_CPU_SCHEDULE scheduler.
Back to Linux's 'normal' one solve it.
quake3-smp
~198 fps 2. high
~193 fps HIGH
640x480 window on 1280x1024x24/32.
1024x768 window give ~100 fps, again.
This is interesting, though. The use of a different
Roland Scheidegger wrote:
Alex Deucher wrote:
And now the really interesting thing:
The results marked with 1) are obtained BEFORE running fglrx, the result
marked with 2) AFTER running fglrx, i.e. when I did not reboot between
running the fglrx driver and the radeon driver (which in the past lead
Vladimir Dergachev wrote:
After looking in the docs, this determines when one map is used versus two
for mipmaps.
#define R200_PP_TRI_PERF0x2cf8
void set_linear_mip_cutoff(float cutoff)
{
GLuint a;
LOCALVARS;
if(cutoff0)cutoff=0;
a=round((2.0*cutoff)*0x1f);
if(a0x1f)a=0x1f;
Vladimir Dergachev wrote:
whoa. I really thought rv350 was the first chip (from ATI) which could
do brilinear.
fglrx does not always use 0x17 btw, that just seems to be a default
value. You can only set that on a global level?
One could change the register value dynamically, as textures are used,
Dieter Ntzel wrote:
I get this even with X.org CVS.
The texture problem is not persistent but the text 'of by oen or two'.
http://www.nuetzel-hh.de/public/Celestia-Mesa-CSV-r200.png
What version of Celestia is this? I get neither of these bugs here
(celestia 1.3.0).
Roland
Ian Romanick wrote:
Roland Scheidegger wrote:
The blending seems to stay exactly the same, just the area where it's
happening gets smaller. This ain't so hot, newer chips seem to do a
better job there. Still, it might make sense to implement that as an
user option, especially since it's so dead
Since 2 people have asked for it, here are some quick numbers for r200
dri vs. fglrx.
r200 dri is using 45MB local tex heap (I believe fglrx reseverves pretty
much anything for textures too, so that's only fair...). btw fglrx
certainly has made some progress, what I noticed is at least 2d
Ian Romanick wrote:
Roland Scheidegger wrote:
Any ideas what's causing this? Maybe fglrx reconfigures the card's
caches or something like that? It would be nice if we could get that
additional 10-15% performance, especially if it is as simple as
writing a single register...
My guess would
Alex Deucher wrote:
And now the really interesting thing:
The results marked with 1) are obtained BEFORE running fglrx, the result
marked with 2) AFTER running fglrx, i.e. when I did not reboot between
running the fglrx driver and the radeon driver (which in the past lead
to lockups, but driver
Adam Jackson wrote:
On Thursday 10 February 2005 11:18, Roland Scheidegger wrote:
r200 dri uses xorg cvs head, with dri driver from Mesa cvs head, with
color tiling, texture tiling, hyperz and whatever else I could find
boosting performance :-).
fglrx uses XFree86 4.3.99.902 (from suse 9.1
Stephane Marchesin wrote:
Dieter Ntzel wrote:
r100-readpixels-3.patch (Stephane)
r200_pntparam_1.diff (Roland)
I'm ran with both.
Should they merged?
I surely hope to get my readpixels patch merged. However, I found a
serious flaw in it (not related to the readpixe segfault) which I have
to fix
Adam Jackson wrote:
On Thursday 10 February 2005 12:53, Roland Scheidegger wrote:
Adam Jackson wrote:
On Thursday 10 February 2005 11:18, Roland Scheidegger wrote:
r200 dri uses xorg cvs head, with dri driver from Mesa cvs head, with
color tiling, texture tiling, hyperz and whatever else I could
Felix Kühling wrote:
I simplified this idea a little further and attached a patch against
texmem.[ch]. It frees stale textures (and also place holders for other
clients' textures) that havn't been used in 1 second when it runs out of
space on a texture heap. This way it will try a bit harder to
Jon Smirl wrote:
AGP 8x should just be able to keep up with 1280x1024x24b 60
times/sec.
AGP 4x should be enough. Remember I got 600MB/s max throughput. Not with
24bit textures though, the Mesa RGBA-BGRA conversion takes WAY too much
time to achieve that.
How does mesa access AGP memory from the
101 - 200 of 492 matches
Mail list logo
