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. Nor
On 25.06.2009 10:32, Stephane Marchesin wrote:
> On Thu, Jun 25, 2009 at 09:46, Jerome Glisse 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 t
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)
>
> DAT
On 30.03.2009 06:23, Dave Airlie wrote:
> On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie 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 surface as
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
>
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
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,
>>> t
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
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 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 refacto
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 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
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).
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 hardwa
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.
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
fall
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 me
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,
> WAIT_HOST_
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 simi
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
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 f
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 te
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
palett
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Roland Scheidegger wrote:
>
>> Indeed this show up every once in a while. A driconf option might be a
>> good idea, but it doesn't solve the problem really for the hardware
>> whic
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
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 +
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
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 dif
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 an
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:
>>> >&g
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
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
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
>> em
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 hel
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 i
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:
>>> 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
>>
>> 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
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'
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
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 Option"BusTyp
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
xpr
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 chec
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
tex
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
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
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
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 _mesa_add_state_r
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
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
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 poi
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' fai
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 ab
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
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: r200VtxFmtFl
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' fai
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
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 +
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 be
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 locke
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
>>
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 pro
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
>
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 matt
Dieter Nützel wrote:
Am Dienstag, 30. Mai 2006 00:33 schrieben Sie:
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’:
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 - ZSmoot
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 m
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 i
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
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 drive
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
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 indefinitely
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 probl
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 can
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
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 de
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 downloa
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. T
Pawel Salek wrote:
Hi,
(Q1) Can anybody summarize shortly what's the status of X600 (PCIID:
5B62, PCIE RV370 type card) support? I see its PCIID is still absent in
shared-core/drm_pciids.txt in spite of few success reports:
http://sourceforge.net/mailarchive/message.php?msg_id=14645441 (BSD)
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, it'
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
Sergio Monteiro Basto wrote:
On Sat, 2006-02-04 at 11:04 -0700, Brian Paul wrote:
Sergio Monteiro Basto wrote:
Includes updates of the DRI drivers and GLX code ?
I don't recall any DRI/GLX check-ins to the 6.4 branch. It's up to
the DRI developers to check in bug fixes to the stable branch,
Benjamin Herrenschmidt wrote:
On Fri, 2006-02-17 at 19:37 +0100, Roland Scheidegger wrote:
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
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 exact
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
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
A
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 the
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
TJ wrote:
Hi,
I have a Dell R300 of some sort. Its PCI ID was not in drm_pciids.h
so I added: (didn't know so added both heads listing)
{0x1002, 0x5b60, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300},\
> {0x1002, 0x5b70, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
2nd head should not be added. It's
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 app
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 r
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
copy
1 - 100 of 528 matches
Mail list logo
