On 21.08.2009 11:45, Tom Cooksey wrote:
Hello,
I'm a Qt developer.
We want all Qt rendering to be done using OpenGL 2. We have this working
pretty well (a few artifacts still here and there). However, we've found some
fundamental problems using GL for regular widget rendering. Normally
On 25.06.2009 10:32, Stephane Marchesin wrote:
On Thu, Jun 25, 2009 at 09:46, Jerome Glissegli...@freedesktop.org wrote:
On Wed, 2009-06-24 at 22:32 +0200, Roland Scheidegger wrote:
On 24.06.2009 20:17, Jerome Glisse wrote:
I think we should let user ask at gem map ioctl time if userspace
On 24.06.2009 20:17, Jerome Glisse wrote:
I think we should let user ask at gem map ioctl time if userspace wants
an surface backed mapping or not, and gem map will reply with a success
or failure. So if object is in vram and there is a surface reg available
it will succeed, if object is in
On 16.04.2009 01:18, Keith Packard wrote:
Digital Enterprise Group (DEG) Software Solutions Group (SSG)
_
FROM:
Angela Gill (Visual Computing Group), and Keith Packard (Open
Source Technology Center)
DATE:
On 30.03.2009 06:23, Dave Airlie wrote:
On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie airl...@gmail.com wrote:
Does anyone remember why we've only done macro tiling on the radeon
for the color buffer so far?
/me discovers the reason ouch.
So the 2D engine can't deal with a microtiled
On 02.03.2009 10:29, Dave Airlie wrote:
Hi Roland,
when you tested my radeon-rewrite was it on an r100 or r200?
Can you check with a clean master checkout whether page flipping works
for you at all?
please can you re-test radeon-rewrite as well, I've pushed a rewrite of
the fb handling
On 19.02.2009 12:23, Arkadi Shishlov wrote:
Roland Scheidegger wrote:
I suspect you're hitting a r200 asic bug, which isn't present in rv250
and other r200 family members. There are workarounds in the driver for
this (see r200UpdateTextureState), but to my knowledge they are
insufficient
On 18.02.2009 13:19, Arkadi Shishlov wrote:
Hi!
I have Radeon8500LE 128MB AGP successfully running under Fedora Rawhide and
DRI is working, but I
tried Doom3 and it freezes at loading screen.
I understand that priorities may have shifted to get R5xx-R7xx cards into 3D,
but until new
On 13.02.2009 05:49, Dave Airlie wrote:
Compressed textures also seem to be broken, since they'll raise a FPE:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1480239424 (LWP 11180)]
0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
target=3553,
On 12.02.2009 06:29, Dave Airlie wrote:
Hi,
So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
work.
So with that in mind and not wanting to write this 3 times, I've done a
major refactoring of
On 12.02.2009 13:48, Roland Scheidegger wrote:
On 12.02.2009 06:29, Dave Airlie wrote:
Hi,
So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
work.
So with that in mind and not wanting to write
On 12.02.2009 15:10, Roland Scheidegger wrote:
On 12.02.2009 13:48, Roland Scheidegger wrote:
On 12.02.2009 06:29, Dave Airlie wrote:
Hi,
So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
work
On 24.10.2008 04:34, Esben Stien wrote:
I've pulled GIT xf86-video-ati for some months now and I always have
to apply this patch:
diff --git a/src/radeon_video.c b/src/radeon_video.c
index ac60166..c400468 100644
--- a/src/radeon_video.c
+++ b/src/radeon_video.c
@@ -1597,5 +1597,8 @@
On 07.08.2008 09:08, Michel Dänzer wrote:
On Wed, 2008-08-06 at 18:12 -0600, Brian Paul wrote:
Svilen wrote:
3 GLX Visuals
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
On 20.07.2008 19:32, Corbin Simpson wrote:
Howdy. I was just going through the r3xx/r5xx bugs, and I noticed that
lots of problems are related to certain texture compression features
being dependent on out-of-tree code. I also noticed that, at least on
R400+ Radeons, we actually have hardware
On 21.07.2008 22:09, Philipp Klaus Krause wrote:
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced
it). Wine and
On 21.07.2008 23:10, Corbin Simpson wrote:
Philipp Klaus Krause wrote:
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user
On 07.06.2008 23:42, Dave Airlie wrote:
Each of the following changes individually fixes the problem:
1) Do not overwrite the same region of the framebuffer in every iteration;
instead, use a different framebuffer region for every iteration.
2) Add a sleep(1) before glReadPixels.
3) Add a
khaqq wrote:
On Wed, 16 Apr 2008 04:34:17 -0700 (PDT)
smoki [EMAIL PROTECTED] wrote:
This is happen in r200 driver, because when i use software TCL pipeline it's
correct.
Is there anybody who can handle this?
Ok, I've verified this. This is standard z-fighting due to a tcl
fallback (so in
khaqq wrote:
On Wed, 16 Apr 2008 04:34:17 -0700 (PDT)
smoki [EMAIL PROTECTED] wrote:
This is happen in r200 driver, because when i use software TCL pipeline it's
correct.
Is there anybody who can handle this?
In what level was that?
Roland
Jerome Glisse wrote:
How storing state will done is yet to be determined but the idea is that
finding state with a given id would have to be fast, very fast. Each
state class will have at much 64dword and i think that there will be
somethings around 30 differents class so this isn't much
Jerome Glisse wrote:
Hi,
So while playing with buffer move i am facing a problem and
would like to know if anyone ever faced it. I emitting a bitblt
multi to move data from ttm to vram just after the bitblt multi
there is a WAIT_UNTIL packet emitted with WAIT_2D_IDLECLEAN,
Jose Rodriguez wrote:
On 30/10/2007, *Roland Scheidegger* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays
with a count of 0 (which is legal though pretty much a no-op), it seems
we don't handle that correctly
Brian Paul wrote:
Roland Scheidegger wrote:
git master still would have the same problem as far as I can see.
The attached simple patch might fix the problem, if it really is what I
think it is :-).
I'm a bit unsure if DrawElements might have a similar problem, the same
problem shouldn't
Jose Rodriguez wrote:
On Mon, 29 Oct 2007 22:50:06 +0100
Roland Scheidegger [EMAIL PROTECTED] wrote:
Also, could you provide a backtrace
from gdb? What are the max_index and min_index values?
Er...not sure, there are a couple of values for each. Take a look
below, please.
#5 0xb69c9ad9
Jose Rodriguez wrote:
Hi
I can't run Gtkradiant
(http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon
driver and the following hardware/software:
01:00.0 VGA compatible controller: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10]
Libraries and driver from Debian testing
Philipp Klaus Krause wrote:
Some time ago Vector Quantisation (VQ) texture compression was
implemented in some chips like the PowerVR series or the ATI MAch64 and
R128.
Is this still supported by today's hardware?
I think the VQ schemes were basically implemented like an extension of
paletted
Alex Jackson wrote:
Neither the i830 nor 965gm actually support GL_CLAMP natively (yay
for d3d-only hardware). The different appearance is caused by the
965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830
maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying
that
James C Georgas wrote:
Forwarded Message From: James C Georgas
[EMAIL PROTECTED] To: Roland Scheidegger
[EMAIL PROTECTED] Subject: Re: GL_CLAMP on D3D-only
hardware Date: Sun, 12 Aug 2007 12:30:51 -0400
On Sun, 2007-12-08 at 12:42 +0200, Roland Scheidegger wrote:
Alex
James C Georgas wrote:
On Sun, 2007-12-08 at 19:09 +0200, Roland Scheidegger wrote:
Yes, though it still requires user interaction to switch the
behaviour - and few people actually seem to know about driconf,
distros don't install it by default etc :-(. I don't think there
were really any
Christoph Brill wrote:
Hi list,
attached are few fixes for issues I found while browsing through the
r200 DRI code.
Looks good to me. I fail to see how the max value for aniso could ever
be less than 1 but I guess the change shouldn't hurt anyway...
Roland
Christoph Brill wrote:
Hi,
find attached some minor cleanups I did while comparing r200 and r300
code. Most of them are indention and cosmetical changes. Only real
changes are that I replaced som
if (0)
with
if (R200_DEBUG DEBUG_TEXTURE)
It generally reduces the diff between
Dave Airlie wrote:
Okay the GART is working fine on the rs480 from my branch, however the
r300 driver causes a chip lockup, I've loaded fglrx and from what I can
see it disables the Vertex Shaders in hw and does that bit of the pipeline
in sw.. at least on the system I have...
If anyone
Christoph Brill wrote:
Attached is a mini-patch to add the address of early Z to r300_reg.h
and use it. Jerome Glisse helped me with this patch. Thanks. :-)
Not really related directly to the patch itself, but it seems to me that
the conditions when to enable early-z are a bit wrong. First, I'd
Keith Whitwell wrote:
Jerome Glisse wrote:
On 2/26/07, Keith Whitwell [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 2/26/07, Roland Scheidegger [EMAIL PROTECTED] wrote:
Christoph Brill wrote:
Attached is a mini-patch to add the address of early Z to r300_reg.h
and use it. Jerome
Christian Neumair wrote:
Dear DRI mailing list,
I'm trying to make my Radeon Mobility M300 (probably PCIE) which is
reported as
01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon
Mobility M300]
work with the EGL demos. This is because I'd like to help out with EGL
Roland Scheidegger wrote:
Rune Petersen wrote:
This patch: - Fixes COS. - Does range reductions for SIN COS. -
Adds SCS. - removes the optimized version of SIN COS. - tweaked
weight (should help on precision). - fixed a copy paste typo in
emit_arith().
Roland would you mind testing
Adam K Kirchhoff wrote:
FYI,
I decided to give ut2004 a spin this morning, for the first time with
the free driver in quite a while. I had heard good things since the VBO
merge... Unfortunately, I very quickly ran into a problem with I loaded
up the Icefields Bombing Run level:
Roland Scheidegger wrote:
Adam K Kirchhoff wrote:
FYI,
I decided to give ut2004 a spin this morning, for the first time with
the free driver in quite a while. I had heard good things since the VBO
merge... Unfortunately, I very quickly ran into a problem with I loaded
up
Rune Petersen wrote:
This patch: - Fixes COS. - Does range reductions for SIN COS. -
Adds SCS. - removes the optimized version of SIN COS. - tweaked
weight (should help on precision). - fixed a copy paste typo in
emit_arith().
Roland would you mind testing if the tweaked weight helped?
Rune Petersen
Ok commited.
I didn't look too closely at this but I've a couple of comments.
- COS looks too complicated broken. If you'd want to get 2 with a
LOG2, you'd need 0.25 as source. But even using RCP instead, that's 5
instructions before performing the sine, for something you can
Roland Scheidegger wrote:
Rune Petersen
Ok commited.
I didn't look too closely at this but I've a couple of comments.
- COS looks too complicated broken. If you'd want to get 2 with a
LOG2, you'd need 0.25 as source. But even using RCP instead, that's 5
instructions before performing
Daniel Kasak wrote:
Roland Scheidegger wrote:
Daniel Kasak wrote:
Hi all. I'm just reporting the below message, as instructed:
Unknown device ID 5653, please report. Assuming plain R300
You're one year too late...
I'll wonder when reports of new ids from people using old drivers
Daniel Kasak wrote:
Hi all. I'm just reporting the below message, as instructed:
Unknown device ID 5653, please report. Assuming plain R300
You're one year too late...
I'll wonder when reports of new ids from people using old drivers will
stop trickle in :-).
Roland
Phillip Ezolt wrote:
(A simple explanation about the view of memory from the graphics card
vs. the system would be helpful. I found the following, but I could use
more details:
http://lists.freedesktop.org/archives/xorg/2005-May/007673.html)
NOTE:The fglrx 8.32.5 driver makes NO calls to
Phillip Ezolt wrote:
Roland,
On 11/21/06, *Roland Scheidegger* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Phillip Ezolt wrote:
It does get recognized as PCI. However, I had to force it PCIE.
(using OptionBusType PCIE). These cards are
definately PCIE, so
Alex Deucher wrote:
If you want to test the opensource 3D driver, you'll have to enable
it in the DDX (xf86-video-ati) and remove the checks from the 3D
driver (r300 in mesa) that keep it from loading on XPRESS hardware.
There is actually no code in the dri driver preventing loading it on
Alan Grimes wrote:
When I run the CVS R200 kernel modules, many megabytes of
synchronization errors appear in xorg.log and it still crashes when I
run any GL app, including glxinfo. It doesn't matter what version of
Mesa I'm running, it should be impossible to crash the kernel like this.
=\
Brian Paul wrote:
Well, if my theory is sound, then the glean pixelFormats test is wrong.
I don't think the test is wrong as-is. It's just that GL_COMBINE mode
exercises things in a different way. A better way, in fact.
I'll clean up your patch, Roland, and check it in. I'll check if
Jerome Glisse wrote:
According to fragment program extension, TEX, TXP, ... should
give you the right A value (Ap depending on which texture unit
you are using).
That's not how I read that. TEX,TXP,... refer to texture sampling
only, there is no thing as previous unit there. Thus, for an RGB
Jerome Glisse wrote:
Hi,
I am wondering if i am fully understanding how texture value should
be computed. I am refering here to section 3.8.13 of opengl
specification and specialy to table 3.21.
My understanding is that when you got an RGB texture the As = 1 but
when computing you use
Keith Whitwell wrote:
Now I remember why I can't use radeon-dri.drawable, at least not
directly when the shader code is added:
When the window size changes the constants have to be updated.
Is there a way for the driver to update a constant after construction?
This is an age-old
GhePeU wrote:
I searched with google and in the X mailing lists for the current status
of the free source r300 driver, but I couldn't find any clear statement
about the Hypermemory feature; most pages or posts were outdated or
vague.
So the main question is: does the r300 open source dri
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
programs, instead of using
So, when trying to implement ARB_point_parameters and ARB_point_sprite,
I came across some problem (this tnl stuff is hard to follow). The
problem is, I need to set some hardware state dependant on the primitive
being renderered (in particular, r200 needs perspective correction
disabled for
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Roland Scheidegger wrote:
So, when trying to implement ARB_point_parameters and
ARB_point_sprite, I came across some problem (this tnl stuff is
hard to follow). The problem is, I need to set some hardware state
dependant
Roland Scheidegger wrote:
I thought there was a mechanism that allowed the driver to be
notified at glBegin (or similar) time. It seems like you ought to be
able to emit some extra state at that time to change to / from
point-sprite mode.
Ah, sounds like a plan. I thought the NotifyBegin
Roland Scheidegger wrote:
Dennis Schridde wrote:
Am Sonntag, 27. August 2006 16:56 schrieben Sie:
Dennis Schridde wrote:
Hi!
One of our (Warzone 2100, http://wz.rootzilla.de/) users told us about an
assert that only our game seems to trigger.
---
warzone2100: r200_vtxfmt.c:1044
Dennis Schridde wrote:
Hi!
One of our (Warzone 2100, http://wz.rootzilla.de/) users told us about an
assert that only our game seems to trigger.
---
warzone2100: r200_vtxfmt.c:1044: r200VtxFmtFlushVertices: Assertion
`rmesa-dma.flush == 0 || rmesa-dma.flush == flush_prims' failed.
---
Dennis Schridde wrote:
Hi!
One of our (Warzone 2100, http://wz.rootzilla.de/) users told us about an
assert that only our game seems to trigger.
---
warzone2100: r200_vtxfmt.c:1044: r200VtxFmtFlushVertices: Assertion
`rmesa-dma.flush == 0 || rmesa-dma.flush == flush_prims' failed.
---
Dennis Schridde wrote:
Am Sonntag, 27. August 2006 16:56 schrieben Sie:
Dennis Schridde wrote:
Hi!
One of our (Warzone 2100, http://wz.rootzilla.de/) users told us about an
assert that only our game seems to trigger.
---
warzone2100: r200_vtxfmt.c:1044: r200VtxFmtFlushVertices: Assertion
Rune Petersen wrote:
Hi,
Quake3 causes fallback because r300_translate_vertex_shader() returns
early and doesn't translate the shader.
The culprit:
if (!mesa_vp-Base.String)
return;
To me it looks suspect because checking a pointer to the shader string
to verify that the parsed
Rune Petersen wrote:
Hi,
I had absolutely no luck getting any usable R300_CP_IB_BASE address with
glxtest.
I get and address like this 0xe0711000 which is not a valid address for
the application. Am I missing something obvious?
Neither can I recently (though I use it for r200). I believe
Adam K Kirchhoff wrote:
Just thought I'd post some updated benchmarks of Doom3. These were
all run with the first timedemo at 640x480, and (for the open source
drivers) with ColorTiling turned on in the xorg.conf file. I'll
list all tests with the open source drivers first:
x700 + r300
Rune Petersen wrote:
Roland Scheidegger wrote:
Adam K Kirchhoff wrote:
Just thought I'd post some updated benchmarks of Doom3. These
were all run with the first timedemo at 640x480, and (for the
open source drivers) with ColorTiling turned on in the xorg.conf
file. I'll list all tests
Tilman Sauerbeck wrote:
If there are no objections, I'll commit this in a few days.
Wouldn't it be simpler to just change t_src to always apply
src-NegateBase? I can't see a need for that src-NegateBase ?
VSF_FLAG_ALL : VSF_FLAG_NONE, as the mesa parser sets all 4 bits anyway
when normal
Michel Dänzer wrote:
Indeed. The X server's GetTimeInMillis() might be more convenient
than gettimeofday() (and would also work with an elfloader X server
;).
Ah yes. That was just a quick hack :-). The question is, what should the
timeout value be?
For determining if the chip has locked up
Michel Dänzer wrote:
On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote:
Looks like quite some more work is needed to detect real lockups but not
just randomly reseting the chip when there is none (which can itself
lead to lockups IME).
Maybe, or maybe it's just a matter
Roland Scheidegger wrote:
Michel Dänzer wrote:
On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote:
Looks like quite some more work is needed to detect real lockups but
not just randomly reseting the chip when there is none (which can
itself lead to lockups IME).
Maybe, or maybe
Tilman Sauerbeck wrote:
Hi,
I finally ran glean today, and noticed that SWZ wasn't implemented
properly for r300 ARB vertex programs.
So far I didn't handle per-component negation flags, the attached patch
adds that.
Question: is it okay to assume that NegateBase in
struct
Michel Dänzer wrote:
On Sun, 2006-05-28 at 19:57 +0200, Roland Scheidegger wrote:
Rune Petersen wrote:
(e.g. while (ret (errno == EINTR || errno == EBUSY));)
And by looking at it, does it make sense that the timeout value in the
kernel depends on the kernel-of-the-day HZ value, rather than
Jacek Poplawski wrote:
I build Quake3 from source and on my r300 Mesa CVS falls into indirect
rendering just after video mode initialization (tried both SDL GL and
GLX drivers). I thought that stencil is the reason, but disabling it
didn't help. There are no r300 warnings visible (there are in
Dieter Nützel wrote:
Latest Mesa and DRM CVS:
r200_sanity.c:163: warning: excess elements in array initializer
r200_sanity.c:163: warning: (near initialization for ‘packet’)
r200_sanity.c: In function ‘radeon_emit_veclinear’:
r200_sanity.c:945: error: ‘drm_radeon_cmd_header_t’ has no member
Dieter Nützel wrote:
Am Samstag, 27. Mai 2006 19:13 schrieben Sie:
Rune Petersen wrote:
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh
Rune Petersen wrote:
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like that ioctl will actually never return
EAGAIN, maybe the original intention was to just wait
Aapo Tahkola wrote:
On Sun, 28 May 2006 19:57:40 +0200
Roland Scheidegger [EMAIL PROTECTED] wrote:
Rune Petersen wrote:
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like
Benjamin Herrenschmidt wrote:
It should probably be infinite if no hw lock is being held.
Lock should be dropped in case of longer waits so that user is given a chance
to stop the process.
Well, the current behaviour (i.e. return EBUSY after 3 seconds) would
make sense too, the user-space
Rune Petersen wrote:
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh Triangles
Not an important app, but other apps might run in to this
in the r200 driver, R200_CMD_BUF_SZ is 8*1024. Is it possible to change
that? I couldn't really find a reason why it's 8k, seems like an
arbitrary choice. There is some comment in r200_ioctl.h for what that
constant is used but it doesn't explain the value. Especially since the
indirect buffer
Ok here's what I came up with, I'm going to commit it soon, though there
really are some ugly hacks in there needed to prevent lockups, (related
to setting/restoring the tcl outputs), maybe someone has any ideas?
The vertex program translation code is pretty taken from the r300
driver, which
Pawel Salek wrote:
ColorTiling works like a charm: it gives factor two speedup in glxgears,
one can play RTCW at 1280x1024 *and* the random lines are gone! Is there
any reason this option is not the default?
I am not sure, maybe it could be made the default by now?
Historically, it is off by
William L. Thomson Jr. wrote:
Hello all, I have a ATI xpress200M in my new HP laptop. Chipset is
5955. I have not had any luck with drivers, dri/drm. I would rather
go the open source route rather than binary ATI. I was hoping to use
the radeon driver and drm from this project.
Now after
Daniel Kasak wrote:
Alex Deucher wrote:
On 3/23/06, Daniel Kasak [EMAIL PROTECTED] wrote:
Hi all.
I've been using the fglrx driver with my Radeon X700 mobility since I
got it, and now I'd like to try to move to the r300 driver. I'm not
getting DRI enabled for some reason that's beyond me ...
Adam K Kirchhoff wrote:
I had some time yesterday and thought I'd do a quick comparision of
the DRI drivers and fglrx drivers for three different cards I have,
and I thought others on this list might be interested in the results.
All tests were conducted on a dual 2.8 xeon, with a gig of RAM.
Felix Kühling wrote:
Log message: Add all radeon pci ids known by ddx, but only
r350/rv350 and below (new chips may be problematic).
Not quite. It's still missing 0x3150 which is the M24 in my notebook.
Fglrx identifies it as MOBILITY RADEON X600 (M24 3150). It works
just fine with the free
Benjamin Herrenschmidt wrote:
I found the problem I introduced with Page Flipping, I pushed a fix
to CVS, however, I still see a (different) issue. I don't think it
was introduced by my patch but I don't have an old X to test with at
the moment...
When using Page Flipping, I launch glxgears,
Benjamin Herrenschmidt wrote:
I finally commited the X driver side of the radeon memory map patches to
the xorg CVS.
I just noticed this breaks page flipping here (rv250), obviously with
xaa only (heavy flicker). This is without the drm patch, but I doubt it
makes a difference. To be more
Adam K Kirchhoff wrote:
I have a radeon mobility U1, with the latest and greatest from Mesa and
drm CVS. Blender launches fine, but as soon as I right click on a light
souce to move it around, the display gets very screwed up, making the
application unusable.
http://68.44.156.246/blender.png
Adam K Kirchhoff wrote:
On Wednesday 15 February 2006 14:34, Roland Scheidegger wrote:
Adam K Kirchhoff wrote:
I have a radeon mobility U1, with the latest and greatest from Mesa and
drm CVS. Blender launches fine, but as soon as I right click on a light
souce to move it around, the display
John Clemens wrote:
There was a post on this list at the end of december(?) indicating that
ATI was not interested in helping open source with 3D specs anymore..
I'm guessing they didn't do much with the r300 line either.. but does
anyone know anything or have any official word on whether
Michael Bautin wrote:
The lockups I am experiencing are real hardware lockups, because I
debugged ring head tail position and it does not change. Is it possible
to detect hardware lockup and reset hardware automatically, by the way?
I've read that Longhorn display drivers for existing hardware
Benjamin Herrenschmidt wrote:
Ok, so finally here is a new version of the patch. This time, it's
against modular and it comes with a DRM patch. The X driver and the DRM
patch should both work with the unpatched counterpart though you'll only
get the full benefit of the fixes with both patches
Stephane Marchesin wrote:
Hi,
I was considering how complicated it can be to implement a texture
replacement policy, and then I had the following idea : we could make
use of hardware cocclusion queries on cards that support them to
determine actual texture usage and thus have a good texture
Keith Whitwell wrote:
Right now, I'm primarily concerned with unified memory chipsets, like
i915 and via. This memory manager would be suitable for managing the
AGP memory on non-unified chipsets, but a different implementation
would be needed for the on-card video ram, based more on dma and
Pedro Maia wrote:
Hello, again i'm sending this email, because i have a particular error, in my
system. It only happens with one game in particular, Icculus Quake2, all
others seem to work fine (Enemy Territory, Tuxracer)
My problem is this one
LIBGL_DEBUG=verbose quake2
libGL:
Alex Deucher wrote:
On 12/24/05, Dave Jones [EMAIL PROTECTED] wrote:
On Fri, Dec 23, 2005 at 11:20:34PM +, Dave Airlie wrote:
Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M
for development work on this project. I have some kernel hacking/driver development
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sergio Monteiro Basto wrote:
On Sat, 2005-12-17 at 14:20 -0800, Ian Romanick wrote:
There are several files, including
mesa/glapi/{glapioffsets,dispatch}.h
and mesa/main/{context,api_arrayelt}.c that depend on IN_DRI_DRIVER
Sergio Monteiro Basto wrote:
On Sat, 2005-12-17 at 14:20 -0800, Ian Romanick wrote:
There are several files, including
mesa/glapi/{glapioffsets,dispatch}.h
and mesa/main/{context,api_arrayelt}.c that depend on IN_DRI_DRIVER
being set properly. If it's not set, the drivers *will* be built
Ian Romanick wrote:
At my point of view
defines IN_DRI_DRIVER and USE_EXTERNAL_DXTN_LIB=1 are very specific and
only used in Mesa.
So the patch on bug #5057 ( the last one ) or something similar, don't
see what problems can cause on applying it.
The problem in applying it is that we are in
Adam K Kirchhoff wrote:
I've narrowed down this problem to something that changed in Mesa
between the 5th of December and the 11th, when I first noticed this
problem. I have a system at work with a 9800. I started up NWN (after
first initializing the card with the fglrx driver, of course),
1 - 100 of 492 matches
Mail list logo
