Vladimir Dergachev wrote:
On Tue, 19 Oct 2004, Roland Scheidegger wrote:
Jon Smirl wrote:
Does the new radeonfb driver in the kernel load? It uses the same I2C
initialization code.
excuse my ignorance, but where would I get that new radeonfb driver?
Try latest 2.6.x kernel. You might need
Keith Whitwell wrote:
I don't know how well tested that holes code is - it's pretty awful to
look back on, certainly that code is more complex than it needs to be.
Does doom3 look right with swtcl?
as far as I can see, yes. Actually, it looks pretty awful, faces are
rendered very poorly, all
Eric Anholt wrote:
Certain textures in ut2k3/ut2k4 are still broken (all ground
textures in dm-antalus). Water reflection in the same map is also
broken (this worked in ut2k4 before (though I have some doubts the
texcoords were actually correct but it looked at least somewhat
reasonable) but
Eric Anholt wrote:
This one is nowhere near as thoroughly tested as previous ones. YMMV.
Certain textures in ut2k3/ut2k4 are still broken (all ground textures in
dm-antalus). Water reflection in the same map is also broken (this
worked in ut2k4 before (though I have some doubts the texcoords
Marcello Maggioni wrote:
I've tried your hint of increasing the AGP size with GARTSize option.
Actually, increasing GARTSize will do nothing for the r200
driver, as it doesn't really use GART memory at all (only if you use
Mesa's glx memory allocator) afaik. The r200 driver uses only 1 texture
Marcello Maggioni wrote:
I get :
WARNING: vertex array range in virtual memory (SLOW)
signal caught: Segmentation fault
si_code 1
Trying to exit gracefully..
Shutting down sound hardware
You don't list what you got as renderer, but this sounds to me like you
got indirect rendering. You need to
Dave Airlie wrote:
I know someone asked a while back but I'm not sure anyone concluded what
was happening...
Last night I decided to give the d3demo a go on my r9200 under DRI, my
first attempt involved pointing LIBGL_DRIVERS_PATH to my S3TC enabled
Mesa tree, this works for me for a number of
John Lightsey wrote:
On Tuesday 05 October 2004 09:17, Fryderyk Dziarmagowski wrote:
--- Jacek Popawski [EMAIL PROTECTED] wrote:
Sorry if it is not best place to write about it, but I believe Doom3 is
very important application, and many developers will be interested in
testing it with DRI driver
Dave Airlie wrote:
from r200_texstate.c:1340
maybe needs to be done pairwise due to 2 parallel (physical) tex units ?
looks like that's not the case, if 8500/9100 owners don't
complain remove this...
Anyone want to bet this has something to do with the shock rifle..
probably not but the
Philipp Klaus Krause wrote:
It seems you are using outdated drivers. The current DRI drivers support
about as much extensions as the nonfree ATI drivers.
GL_ARB_vertex_buffer_object is in both software Mesa and the r200
driver.
It should be noted though that ARB_vbo is a fake extension in the r200
Alex Deucher wrote:
On Wed, 22 Sep 2004 18:56:40 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
I think I've seen this one - check your BIOS settings - maybe you need to
enable something AGP related there.
As I recall, since the X server doesn't have official 8x agp support
yet for
Eric Anholt wrote:
Yeah, it was clear that we used to emit in whatever order, and that
would have been nicer. At this point I'm seeing about 5% CPU time in
EmitState for ipers, which seems pretty hefty for such a small bit
of code, but I didn't see much obvious for improvement.
That's indeed
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
memcpying the state atoms off. When we actually see the context get
lost,
Dieter Nützel wrote:
Am Montag, 13. September 2004 22:08 schrieb Dieter Nützel:
I've updated the drm.watchdog.2.patch
http://marc.theaimsgroup.com/?l=dri-develm=108551485018672w=2
to latest DRM CVS and it works together with
ati.unlock.1.patch and ati.drm-r300-version.1.patch
Marcello Maggioni wrote:
On Sun, 12 Sep 2004 00:34:01 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Marcello Maggioni wrote:
My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the
lastest taken yesterday from CVS.
I've downloaded the demo , and the game seemed to run fine
Marcello Maggioni wrote:
My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the
lastest taken yesterday from CVS.
I've downloaded the demo , and the game seemed to run fine at
least until I tried to shoot with a Shock Rifle .
Just after the laser beam started to run from my rifle
Roland Scheidegger wrote:
Dieter Ntzel wrote:
Only some rejections in
src/mesa/main/texcompress_s3tc.c
I'll fix it, but you have to wait at least another full week.
Ok, new version can be found as usual at
http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
Roland
Mike Mestnik wrote:
Most IMPORTANT is that some-one some-where there is a list of ALL of
these. These are best in the form of code comments so the the respective
places in the code can be changed.
--- Dave Airlie [EMAIL PROTECTED] wrote:
Dose the DRM varify that the cmds are in this order? Why
Dieter Ntzel wrote:
Only some rejections in
src/mesa/main/texcompress_s3tc.c
I'll fix it, but you have to wait at least another full week.
Roland
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer
Keith Whitwell wrote:
Since the driver supports GL_NV_texture_retangle,
GL_EXT_texture_retangle and probably soon will GL_ARB_texture_retangle
I wonder why GL_ARB_texture_non_power_of_two isn't supported.
Because nobody's done the work to support it. It shouldn't be that hard
- the main
Roberto Sanchez wrote:
I have followed the instructions provided by Roland Scheidegger:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
I was able to get DRI, Mesa, and DRM to compile and run. I then
applied Roland's patches and recompiled, and again everything worked
Aapi Hämäläinen wrote:
pe, 02-07-2004 kello 11:20 +0200, Michel Dänzer kirjoitti:
Yes, those are all symptoms of chip lockups. The watchdog and engine
reset patches discussed recently might help to some degree, but of
course the best thing would be to find and fix the bugs that cause the
Yesterdays and todays checkins (to some glapi files I think) seem to
cause some severe problems for me (i'm using drivers/libGL built from
dri tree). I'm not sure, maybe it's because I'm using a quite old system
(suse 8.1, kernel 2.4.26), with old pthread library etc.
Some things (quakeIII, rtcw,
Felix Kühling wrote:
On Thu, 1 Jul 2004 20:09:58 +0200
Dieter Nützel [EMAIL PROTECTED] wrote:
Am Sonntag, 13. Juni 2004 09:24 schrieb Dieter Nützel:
Am Sonntag, 13. Juni 2004 09:01 schrieb Dieter Nützel:
Empty black window.
With 'Point' and 'Linear' Filtered.
Mesa (LIBGL_ALWAYS_INDIRECT) works.
[EMAIL PROTECTED] wrote:
Hi!,
I have a Debian SID runing on hp-compaq nx9010 laptop with ATI
Radeon
Mobility IGP345M
After a lots of tries to compile dri+drm+mesa I got the errors
attached
in this mail.
In file included from r200_context.h:41,
from r200_sanity.c:41:
Thomas Hellström wrote:
Hi!
I'm trying to compile the unichrome_dri.so driver in the xc tree with
latest Mesa cvs. When the driver is loaded I get a missing symbol
_tnl_init_c_codegen.
Something new I've left out?
I've get that for r200 too. Seems to be related to the t_vertex.c
codegen
Dieter Nützel wrote:
gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main
-I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl
-I../../src/mesa/shader -I../../src/mesa/swrast -I../../src/mesa/swrast_setup
-Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE
Since the patch broke again...
a new version together with some information how to install it can be
found here (that also means I no longer have to spam the list for future
versions).
http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
Roland
Dave Airlie wrote:
Okay finally after using a pen and paper to draw some pictures I've gotten
compressed textures to work with Neverwinter nights!!
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Ok, I've updated my patch.
I've converted the r200 and radeon driver to use I8 internal format for
GL_INTENSITY, GL_LUMINANCE and GL_ALPHA formats (so that bug with
conversion to GL_LUMINANCE_ALPHA wouldn't get triggered in the first
place now...), the textures are stored by mesa in mesa_texformat_i8,
-l8, and -a8
Dieter Nützel wrote:
Am Montag, 14. Juni 2004 17:25 schrieb Dieter Nützel:
Am Montag, 14. Juni 2004 13:42 schrieb Dave Airlie:
texcmp isn't working for me but I can't see what is wrong on my machine,
something may have broken it recently...
it no longer for me prints the extra info ..
You mean the
Ryan Underwood wrote:
On Thu, Jun 03, 2004 at 01:34:58AM +0200, Roland Scheidegger wrote:
[EMAIL PROTECTED] wrote:
Hi,
I'd like to know where is the texture compression now?
Has it been integrated to the mesa tree or is it still provided in a
separate library ?
It is still in a separate library
Dieter Nützel wrote:
Am Donnerstag, 10. Juni 2004 11:59 schrieb Dieter Nützel:
Am Dienstag, 8. Juni 2004 00:14 schrieb Roland Scheidegger:
Dave Airlie wrote:
I've fixed the FXT support but DXT1 RGB is still knackered and
probably won't be fixed...
http://www.skynet.ie/~airlied/patches/dri
Dave Airlie wrote:
When I run nwn with the i830 advertising GL_EXT_texture_compression_s3tc,
either by making the lib available or forcing the option in drirc, I get a
wierd lighting interaction..
http://www.skynet.ie/~airlied/dri/screen/NWNa.jpg
vs with s3tc off.
Dave Airlie wrote:
I've fixed the FXT support but DXT1 RGB is still knackered and probably
won't be fixed...
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Roland can you update your patch with this verson?
Done (I've changed it slightly though since you can use fxt without the
dxt
Michel Dnzer wrote:
A simpler option would be to axe support for AGPSize...
I don't think we should break working configurations as long as we
can support them so easily.
Ok.
Couldn't it just use the largest GART size possible (set by the
bios), or would this have some negative consequences?
It
Felix Kühling wrote:
It could waste a lot of RAM.
But is this a problem? It surely eats away some of the 3GB user address
space I believe (afaik the low-mem kernel address space agpgart takes is
gone anyway), but unless the driver is really stupid and just fills it
up even if it doesn't need to
Roland Scheidegger wrote:
There's historically been code which tried to do that, but it
just never ever worked...
I always thought that the code did work, however since the reset
usually happened in DRM driver it did not know how to set the mode.
There were quite a few occasions where I
Ian Romanick wrote:
implications. What if one process removes the backing from a region
of the AGP aperture a the same instant another process tries to
texture from that range? Random memory reads? System crash? Dunno...
This just can't heppen, no sharing of AGP space, right?
Video memory
Vladimir Dergachev wrote:
On Wed, 26 May 2004, Keith Whitwell wrote:
Vladimir Dergachev wrote:
Hi Nikolai,
I merged your patches - thank you very much !
I wonder if a similar approach could allow us to reset the radeon/r200
after lockups?
Well, Nikolai's patch is not specific to R300 - it
Ian Romanick wrote:
Manuel Bilderbeek wrote:
(II) RADEON(0): [agp] GART texture map handle = 0xe0302000 (II)
RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Will use
2752 kb for textures at offset 0x1d5
The card has 32MB RAM and I'm usually running at 1600x1200x24
is this
[EMAIL PROTECTED] wrote:
Hi,
I'd like to know where is the texture compression now?
Has it been integrated to the mesa tree or is it still provided in a
separate library ?
It is still in a separate library, the legal issues have not changed.
If so where can i download it ?
patch here:
Manuel Bilderbeek wrote:
Hello all,
I have been using the latest Debian packages from Michel Daenzer
since a few years and that solved most problems with GL apps.
However, there are still a few left: - in the XScreensaver hack
AntSpotlight, I don't get to see the desktop... Only the ant
walking on
Dieter Nützel wrote:
Am Freitag, 28. Mai 2004 19:22 schrieb Roland Scheidegger:
So, when I updated radeon_maos_arrays.c and compiled that (btw really
brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in
radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that
codepath
i810context.c
In file included from i810context.c:53:
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
parse error before XF86DRIClipRectRec
../../../../../../programs/Xserver/hw/xfree86/drivers/i810/i810_dri.h:81:
warning: no semicolon at end of struct
or union
So, when I updated radeon_maos_arrays.c and compiled that (btw really
brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in
radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that
codepath was only enabled in april 2002 for 9 days and probably caused a
15% slowdown
Ian Romanick wrote:
Nothing about DRI prevents a developer from choosing a different kernel
/ user split. Based on the size of their kernel modules, I'm pretty
sure that both 3dlabs and ATI made a different choice. However, they
support Linux only and they aren't distributed with the kernel
Dave Airlie wrote:
The attached patch provides s3tc (and broken fxt) texture compression
support on the i8xx (x30) chipsets,
You need to apply the radeon/r200 patch from Roland first, Roland do
you want to merge this patch into yours?
Yes, I've merged it. New version can be found here (so I
Dave Airlie wrote:
Doesn't this work with the i830 driver? AFAIK i830 and i845G both use the same
graphic core (intel extreme graphics). i855G/i852G/i865G use intel extreme
graphics 2, which afaik is exactly the same, except it's clocked slightly
higher (266Mhz vs. 200Mhz). At least some people
Jon Smirl wrote:
Any ideas about what this is? It is from the Redhat -2 xorg rpm's. All of these
programs ran fine on SW mesa and R128 driver.
[EMAIL PROTECTED] cairogears]$ ./cairogears -glx COMP
cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset 1023) == 0
' failed.
Aborted
Dave Airlie wrote:
Hi,
I've just gotten an i865 system are there any docs out there for
programming the 3d end of this? Intels site for that chipset has no
programmers reference beyond the datasheet which doesn't say muc about 3D
stuff..
Are these docs available non-NDA?
Doesn't this work
Mark Cass wrote:
guys,
finally have some good news. uploading DXT1, DXT3, and DXT5 compressed
textures is working. i still need to implement compressed sub textures
and test very small textures.
the issue was the tile size. i wrote an iterator into the driver to test
all possible tile sizes
Roland Scheidegger wrote:
Ok, here's a patch to enable separate blend function / equation on r200,
as well as fix glBlendColor. It needs drm changes, I've tried to make it
backward/forward compatible in all ways, except the driver will not
build with old drm sources (so this needs to be applied
Ok, here's a patch to enable separate blend function / equation on r200,
as well as fix glBlendColor. It needs drm changes, I've tried to make it
backward/forward compatible in all ways, except the driver will not
build with old drm sources (so this needs to be applied first, could
someone do
Ian Romanick wrote:
Here's a patch. That 8 is a bit ugly, though. Should I add the
unshifted blend func values to r200_reg.h, together with some
proper defined shifts? I like the blend func value selection better
than before (where there was a huge function where the second half
is (almost)
Chris Pickett wrote:
Chris Pickett wrote:
Hi Roland,
I'm sorry to be so persistent here, but what are the specific steps
(not the exact commands, e.g. checkout pkg X is clear enough) we
need to do to apply this patch to our gentoo systems running (well, at
least in my case) xorg-6.7.0?
My
this new demo fails pretty horribly on r200.
It seems to be caused by the same bug as I reported here,
http://marc.theaimsgroup.com/?l=dri-develm=107854279829216w=2,
something fundamental just doesn't work right with regard to blending.
Even if you never enable blending (or disable it
Ian Romanick wrote:
Roland Scheidegger wrote:
this new demo fails pretty horribly on r200. It seems to be caused
by the same bug as I reported here,
http://marc.theaimsgroup.com/?l=dri-develm=107854279829216w=2,
something fundamental just doesn't work right with regard to
blending. Even if you
Ian Romanick wrote:
Roland Scheidegger wrote:
Ah, missed that in the spec. Seems to be unnecessarily restrictive
to not have a weighting factor for GL_MIN/MAX, apparently common
hardware could do it just fine (or maybe it doesn't make enough
sense to allow it?).
Modern hardware can
Cedric Cellier wrote:
DRI compiled and installed cleanly.
The bug goes away !
Many thanks !
(Note : BTW, now xdm start in BW mode, and refuses to launch X11 - I
had to install another login manager :-/ )
This is probably related to the missing xdm-authorization code in the
DRI built XFree86
Cedric Cellier wrote:
Hi list !
If a post something that have been reported many times, Im sorry.
But I searched to google and to this ML's archive and didn't find
anything close to what I got.
Ive coded a little game (ensemblist, hosted at savannah), and I just
realized that the game does not
Cedric Cellier wrote:
Sorry I should have told :
The driver used by X11 is r200, from the debian package (Sarge),
wich is numbered 4.3.0-7
Sorry, should have mentioned it too, I'm running dri cvs (from some days
ago). So this may be a bug which is already fixed, 4.3.0 is OLD as far
as the dri
Mark Cass wrote:
guys,
I am currently working on putting texture compression support into
the savage driver. I am approaching this in two stages. Stage one is
to get the loading of pre-compressed textures working. Stage two,
would be the driver level compression of textures. I no there are
Dieter Nützel wrote:
Litle rejection on latest Mesa CVS:
src/mesa/main/texcompress_s3tc.c.rej
You're right, here's a new patch. Nothing changed at all, except it
applies again...
Roland
mesa_r200_radeon_txc_cvs040504.diff.gz
Description: Unix tar archive
Here's a new version of the texture compression patch.
Changes:
- Thanks to Brian's changes all (core mesa) changes are now in only one
file (texcompress_s3tc.c), except one boolean variable.
- the texel fetch code works again (not sure why it didn't work last time)
- some small cleanups in the
Wolfgang Köbler wrote:
Hi,
I tried to compile a linux 2.4.26 kernel, but it failed in
/drivers/char/drm/r128_drv.c . I am able to compile a linux 2.4.25 kernel
with the same configuration. The linux kernels are from kernel.org.
The relevant part of the kernel-build-messages probably is:
make[3]:
Roland Scheidegger wrote:
What's new:
- Updated to new texstore code (defined
_mesa_texstore_rgb[a]_dxt[1,3,5]) functions
- dropped the forced compression of all textures. This has cut the patch
size almost in half. Mesa can't handle this (since it decides if a
texture is compressed before
(current cvs of course).
In file included from xf86drmCompat.c:83:
/usr/tmp/dri/drm/linux/i830_drm.h:293: variable or field `__user'
declared void
/usr/tmp/dri/drm/linux/i830_drm.h:293: warning: no semicolon at end of
struct or union
/usr/tmp/dri/drm/linux/i830_drm.h:293: parse error before '*'
Ryan Underwood wrote:
On Wed, Apr 21, 2004 at 02:42:48PM +0200, Vykupitel wrote:
Hello, I've got problem with tdfx driver.Someone told me that tdfx
driver development is halted,but I need to add one type of card to
it.I have Daytona card which is prototype of Voodoo4 4200 with
VSA-101 which
Michel Dnzer wrote:
On Sat, 2004-04-17 at 00:00, Alan Hourihane wrote:
I could merge in XFree86 4.3.99.902 which is before the license
change
Are you sure? AFAIK David applied the new license (or at least a
similarly controversial one) to some files before it was publicly
announced.
This page
Felix Kühling wrote:
On Mon, 05 Apr 2004 14:50:45 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Paul Heldens wrote:
I found on the list that this has always been broken in dri because of a
hardware issue.(?)
Example of affected apps; gtkradiant, blender,maya(hearsay)
Questions:
Is there any
Felix Kühling wrote:
As for the texture compression stuff, I have never tried it myself.
Roland Scheidegger has been working on this for the Radeon and r200
drivers. He can probably give you more information about what is needed
and how it works. I'm not sure how much work it would take
I'm still trying to implement the glblendfuncseparate and
glblendequationseparate (and fix glblendcolor) functions. Since I
couldn't find a demo which tests these extensions, I figured I'd modify
some demo, and this one,
http://www.sgi.com/software/opengl/advanced97/programs/multialphablend.c
Roland Scheidegger wrote:
The reason I didn't commit the changes was I didn't want to commit
untested changes, but I forgot to test it (don't have the radeon handy
all the times). I can commit it (respectively an updated version) if you
want, but AFAIK nobody has tested the driinterface branch
Ian Romanick wrote:
Chris Ison wrote:
ok, looking of the oprofile output of libgl, r200_dri and
qw-client-glx, I decided to hunt for the function
texsubimage2d_bgr888_to_rgba which is at the top of the list at
22.6% of the time.
So, it looks like it's basically converting from one byte
Chris Ison wrote:
I'm wondering though why the heck quakeworld actually uses so much
texsubimage2d calls. Typically, games specify textures at level load
time and leave them completely alone after that - at least those games I
profiled with oprofile never showed texsubimage2d calls. Is there
(also cc to dri-devel, not all developers might read dri-users)
Bernhard Wymann wrote:
Hi all
I'm a developer of the TORCS (The Open Racing Car Simulatior)
project, look at www.torcs.org. A user reported that the
initialization of TORCS 1.2.2 fails with his Matrox g550. I post here
because I
Felix Kühling wrote:
On Tue, 17 Feb 2004 17:46:48 +0100 Roland Scheidegger
[EMAIL PROTECTED] wrote:
[snip]
The GLX visual matching code is pretty much driver-independant, so
it's odd this would only be a problem with the mga driver. That
said, there were some changes in that area since
Bernhard Wymann wrote:
Hi, nice to hear from you,
If you'd use glutInitDisplayString with depth=16 you _should_ get
a 24bit depth buffer if available though, at least in theory - if
not that would be a bug in glut or the glx visual matching code.
That might be true, but the code runs also on
Michel Dnzer wrote:
On Sat, 2004-02-14 at 02:47, Roland Scheidegger wrote:
[...] the trace tux leaves behind is missing on the R200 (with hw tcl).
Sometimes it shows up but at the wrong place.
That seems to work here.
Strange. I've just checked I'm running the same version, it's also 0.61.
I
Andreas Stenglein wrote:
Am 2004.02.14 00:11:35 +0100 schrieb(en) Roland Scheidegger:
Andreas Stenglein wrote:
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD.
Now with the MULT-code in radeon_state.c radeon_state_init.c
(change lighting to use MULT instead of PREMULT ...) the
shading
Dieter Nützel wrote:
I ask if you have any idea why it (r200 with new lightning, e.g. hardware
accelerated TCL) hangs immediately in Capture the Flag - Citadel when I
use the mouse (only put my hand on it and have some nervous fingers is
enough), but runs fine with cursor keys and both of it
Ok, I was wrong that the radeon driver also doesn't implement this
correctly. It just always uses a fallback, it just doesn't support it in
hardware. That said, I'm wondering what's the purpose of announcing
ARB_imaging support, at least out of the three blend extensions this
includes
Keith Whitwell wrote:
Roland Scheidegger wrote:
When I was playing around with texenv (I'm trying to implement
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the
R200, though my attempts to modify texenv to make it a useful test for
that were unsuccesful), I've noticed
Keith Whitwell wrote:
Am I missing something -- isn't this setting the appropriate
blend modes? Is the constant color not getting updated
correctly?
Yes, exactly, the constant color isn't updated at all (so the color
is _really_ constant ;-)). Mesa would call ctx-Driver.BlendColor
to
Keith Whitwell wrote:
As far as I can see though this would get very ugly, with lots of if
drm_version code. And it might not be necessary (for instance if the
BLENDCNTL register just mirrors the CBLENDCNTL, but leaves the
values in ABLENDCNTL alone then it would be no problem at all). Maybe
Andreas Stenglein wrote:
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD.
Now with the MULT-code in radeon_state.c radeon_state_init.c
(change lighting to use MULT instead of PREMULT ...) the
shading/lighting of warriors changed a little bit in tcl-mode.
It's been buggy before in
Ian Romanick wrote:
Roland Scheidegger wrote:
Keith Whitwell wrote:
As far as I can see though this would get very ugly, with lots
of if drm_version code. And it might not be necessary (for
instance if the BLENDCNTL register just mirrors the
CBLENDCNTL, but leaves the values in ABLENDCNTL alone
Michel Dnzer wrote:
On Sat, 2004-02-14 at 00:11, Roland Scheidegger wrote:
Just the other day, I've noticed not even the good old tuxracer runs
correct on the R100 on my 2nd PC - the ice areas flickered a lot,
That's a long standing tuxracer bug, Z fighting between several passes
There's a buffer overflow in XFree86 allowing local attackers to gain
root privileges. Here's the patch,
ftp://ftp.xfree86.org/pub/XFree86/4.3.0/fixes/fontfile.diff the advisory
http://www.idefense.com/application/poi/display?id=72type=vulnerabilitiesflashstatus=false
and a demo exploit also
When I was playing around with texenv (I'm trying to implement
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the
R200, though my attempts to modify texenv to make it a useful test for
that were unsuccesful), I've noticed that the radeon and r200 driver
announce
Ian Romanick wrote:
Roland Scheidegger wrote:
Ian Romanick wrote:
In-progress. Please test this branch! :) Would it be possible to
make the R200 nightly snapshot come from the branch instead (or in
addition to) the trunk? I'd like to merge to the trunk next Thursday
(19-Feb-2004). In order
Dieter Nützel wrote:
Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:
On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
[ Following up to the dri-devel mailing list, we aren't really
using the sf.net bug tracker anymore but rather the kernel and
XFree86 bugzillas ]
On Mon, 2004-02-09
Michel Dnzer wrote:
Works perfectly here... Do you have current DRI CVS from
freedesktop.org? If so, please post the errors.
Speaking of that, I've seen some users get dri cvs from sourceforge.net
accidentally. Couldn't someone commit a fix so when you try to build
it you just get some error
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in
the tnl code? The crashes sometimes are predictable (for instance in
the old ut it'll always crash in the intro when the announcer says
in twenty-two ninety
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very
recently in the tnl code
OK, perhaps you could check in the restored version for now. I may
not get to look into this further for a day or two.
-Brian
Oh - such a drastic measure :-(. Is there some way to revert changes in
cvs, or do I just have to submit that as a new version, maybe even with
tricks like update it
Now that I've commited the lighting changes for r200 (still has the
material fallback though), I've wanted to commit the same changes (well
not exactly the same of course ;-)) to the radeon driver too (some brief
testing showed it worked just fine). But I'm a bit confused, the code
I'll need
301 - 400 of 492 matches
Mail list logo
