Dave Airlie wrote:
Both i915 and radeon memory managers could probably be moved over to the new
code, but then only using the functionality in drm_mm.c and not drm_sman.c.
I'll have a look. However, I'd rather focus on getting the ttm branch in a
usable state and start moving drivers
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
> Both i915 and radeon memory managers could probably be moved over to the new
> code, but then only using the functionality in drm_mm.c and not drm_sman.c.
> I'll have a look. However, I'd rather focus on getting the ttm branch in a
> usable state and start moving drivers over to that function
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
I am sorry, I meant quake2, not quake3... :-o
On 5/29/06, Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> 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
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=6357
--- Additional Comments From [EMAIL PROTECTED] 2006-05-30 03:04 ---
I hav
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
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 Cube, which also disables
Brian Paul [2006-05-29 08:42]:
> Tilman Sauerbeck wrote:
> >Hi,
> >I suspect that the vertex attribute changes from 2006-04-26 broke
> >Doom3 on r300.
> >Symptoms:
> >The rendering of Mars in the main menu screen is broken, see the
> >attached screenshot (the planet is supposed to look reddish, not
Tilman Sauerbeck wrote:
Hi,
I suspect that the vertex attribute changes from 2006-04-26 broke
Doom3 on r300.
Symptoms:
The rendering of Mars in the main menu screen is broken, see the
attached screenshot (the planet is supposed to look reddish, not white).
It's also flickering a lot.
Similar pr
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 tha
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=6429
--- Additional Comments From [EMAIL PROTECTED] 2006-05-29 22:19 ---
I sug
I'll have a look. However, I'd rather focus on getting the ttm branch in a
usable state and start moving drivers over to that functionality, eventually
obsoleting the code in drm_sman.c.
Oh no worries don't let me detract from the real problem, I just wondered
having looked in those files be
Dave Airlie wrote:
New semantics:
The new manager always aligns to 16 bytes, except when it is
bypassed by the SiS fb module.
Yes you're right. The core functions support any alignment so the
constraints are device specific.
Just another question, could this code be used to replace al
New semantics:
The new manager always aligns to 16 bytes, except when it is bypassed by
the SiS fb module.
Yes you're right. The core functions support any alignment so the constraints
are device specific.
Just another question, could this code be used to replace all or
parts of i915_m
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 some
Luc Verhaegen wrote:
On Sun, May 28, 2006 at 06:36:27PM +0200, Thomas Hellström wrote:
New semantics:
The new manager always aligns to 16 bytes, except when it is bypassed by
the SiS fb module.
This alarmed me; I don't want to see VIAs problem become a DRM wide
rule.
But it seems
18 matches
Mail list logo
