Vladimir Dergachev wrote:
No special tinkering is required beyound recent Xorg CVS.
Will version 6.8.1.902 (from Gentoo) be recent enough?
Jacob
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source datab
On Thu, 3 Feb 2005, Jacob Gorm Hansen wrote:
Roland Scheidegger wrote:
Jacob Gorm Hansen wrote:
I still get an error in r300, using the freedesktop drm:
Well yes. For radeon and r200 drivers (and apparently savage), you need the
freedesktop drm, since the one from the r300 driver is too old. For
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=1731
--- Additional Comments From [EMAIL PROTECTED] 2005-02-03 20:13 ---
(In
Roland Scheidegger wrote:
Jacob Gorm Hansen wrote:
I still get an error in r300, using the freedesktop drm:
Well yes. For radeon and r200 drivers (and apparently savage), you need
the freedesktop drm, since the one from the r300 driver is too old. For
the r300 driver, you need the r300 drm, as th
Jacob Gorm Hansen wrote:
I still get an error in r300, using the freedesktop drm:
Well yes. For radeon and r200 drivers (and apparently savage), you need
the freedesktop drm, since the one from the r300 driver is too old. For
the r300 driver, you need the r300 drm, as the freedesktop does not
co
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=1731
--- Additional Comments From [EMAIL PROTECTED] 2005-02-03 17:44 ---
Unfo
Vladimir Dergachev wrote:
On Thu, 3 Feb 2005, Jacob Gorm Hansen wrote:
hi, trying to compile mesa with the r300 driver I get the following
error:
r200_ioctl.c: In function `r200PageFlip':
r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
r200_ioctl.c: In function `r200Clear
On Thu, 3 Feb 2005, Jacob Gorm Hansen wrote:
hi, trying to compile mesa with the r300 driver I get the following error:
r200_ioctl.c: In function `r200PageFlip':
r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
r200_ioctl.c: In function `r200Clear':
r200_ioctl.c:635: error:
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=1731
--- Additional Comments From [EMAIL PROTECTED] 2005-02-03 17:25 ---
(In
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=1735
[EMAIL PROTECTED] changed:
What|Removed |Added
-
Roland Scheidegger wrote:
For the Mesa radeon and r200 driver, you need a very recent drm from
dri.freedesktop.org. I've no idea what's in the drm from r300_driver,
but it might be possible it does not contain all recent changes of the
drm from dri.freedesktop.org.
With the latest drm (CVS HEAD)
Jacob Gorm Hansen wrote:
hi, trying to compile mesa with the r300 driver I get the following error:
r200_ioctl.c: In function `r200PageFlip':
r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
r200_ioctl.c: In function `r200Clear':
r200_ioctl.c:635: error: `RADEON_USE_COMP_ZBUF
Jacob Gorm Hansen wrote:
Dave Airlie wrote:
r200_ioctl.c: In function `r200PageFlip':
r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
r200_ioctl.c: In function `r200Clear':
r200_ioctl.c:635: error: `RADEON_USE_COMP_ZBUF' undeclared (first use in
this function)
r200_ioctl.c:6
Dave Airlie wrote:
r200_ioctl.c: In function `r200PageFlip':
r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
r200_ioctl.c: In function `r200Clear':
r200_ioctl.c:635: error: `RADEON_USE_COMP_ZBUF' undeclared (first use in
this function)
r200_ioctl.c:635: error: (Each undeclar
> r200_ioctl.c: In function `r200PageFlip':
> r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
> r200_ioctl.c: In function `r200Clear':
> r200_ioctl.c:635: error: `RADEON_USE_COMP_ZBUF' undeclared (first use in
> this function)
> r200_ioctl.c:635: error: (Each undeclared iden
hi, trying to compile mesa with the r300 driver I get the following error:
r200_ioctl.c: In function `r200PageFlip':
r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
r200_ioctl.c: In function `r200Clear':
r200_ioctl.c:635: error: `RADEON_USE_COMP_ZBUF' undeclared (first use i
Am Freitag, den 04.02.2005, 01:57 +0530 schrieb Rajsekar Manokaran:
> seems to improve the perfomance in quake
Thanks for the feedback. Could you provide some more info, though? Which
quake version? Which hardware and driver? How much local and AGP texture
memory are available in your configurati
seems to improve the perfomance in quake
On Wed, 02 Feb 2005 17:38:21 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote:
> I attached an updated patch that applies to latest CVS and includes a
> fix along the lines of the one I just committed to texmem.c.
>
> I havn't heard any feedback in over a
Rune Petersen wrote:
Alex Deucher wrote:
On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen
<[EMAIL PROTECTED]> wrote:
Do you know who is responsible for the DVI-code?
lots of people have touched that. it could be related to the display
buffer watermark code. perhaps it needs some tweaks for you
Alex Deucher wrote:
On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen <[EMAIL PROTECTED]> wrote:
Do you know who is responsible for the DVI-code?
lots of people have touched that. it could be related to the display
buffer watermark code. perhaps it needs some tweaks for your chip.
take a look at
On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen <[EMAIL PROTECTED]> wrote:
> Vladimir Dergachev wrote:
> >
> >
> > On Thu, 3 Feb 2005, Rune Petersen wrote:
> >
> >> Vladimir Dergachev wrote:
> >>
>
> X is 1280x1024 and the lessons uses 640x480 in full screen.
> >>>
> >>>
> >>>
> >>> I p
Does this fix things for you ?
No, I need 2.
Do you still see the same problem by stretching the window as large as it
can be ?
there are no problems with stretching the window
I've experimented and found that 2 NOPs doesn't really help.
if I set full screen to be the LCDs native resolution it ha
Vladimir Dergachev wrote:
On Thu, 3 Feb 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
X is 1280x1024 and the lessons uses 640x480 in full screen.
I put back a single PFS_NOP as the syntax does not allow for less
than 1 instruction (alu_end==0 corresponds to 1 instruction).
You are right,
Vladimir Dergachev wrote:
Yes, except we have only one instruction to begin with.
Rune, does the fix with alu_offset=0 work for you ?
Yes this is my fault. I forgot to put it in writing.
yes the alu_offset fixed the problem.
Rune Petersen
---
This
On Thu, 3 Feb 2005, Ian Romanick wrote:
Rune Petersen wrote:
looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).
with some more testing I found:
- FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen to
avoid corruption. Can you add these NOPs only when resizing? =)
- SINGL
On Thu, 3 Feb 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
X is 1280x1024 and the lessons uses 640x480 in full screen.
I put back a single PFS_NOP as the syntax does not allow for less than 1
instruction (alu_end==0 corresponds to 1 instruction).
You are right, but why do we get away wit
On Thu, 3 Feb 2005, Rune Petersen wrote:
> > You are quite right - also the following instruction:
> >
> > {
> > EASY_PFS_INSTR0(MAD, SRC0C_XYZ, ONE, ZERO),
> > EASY_PFS_INSTR1(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, NONE,
> > ALL),
> > EASY_PFS_INSTR2(MAD, SRC0A, ONE, ZER
Rune Petersen wrote:
looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).
with some more testing I found:
- FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen
to avoid corruption. Can you add these NOPs only when resizing? =)
- SINGLE_TEXTURE_VERTEX_SHADER needs 1 NOP to ge
Vladimir Dergachev wrote:
X is 1280x1024 and the lessons uses 640x480 in full screen.
I put back a single PFS_NOP as the syntax does not allow for less than 1
instruction (alu_end==0 corresponds to 1 instruction).
You are right, but why do we get away with having 0 tex instruction?
It should be
On Thu, 3 Feb 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
with some more testing I found:
- FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen to
avoid corruption. Can you add these NOPs only when resizing? =)
Not really, but this might indicate a sort of bandwidth is
Vladimir Dergachev wrote:
with some more testing I found:
- FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full
screen to avoid corruption. Can you add these NOPs only when resizing? =)
Not really, but this might indicate a sort of bandwidth issue - one part
is issuing pixels faster t
On Thu, 3 Feb 2005, Rune Petersen wrote:
You are quite right - also the following instruction:
{
EASY_PFS_INSTR0(MAD, SRC0C_XYZ, ONE, ZERO),
EASY_PFS_INSTR1(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, NONE,
ALL),
EASY_PFS_INSTR2(MAD, SRC0A, ONE, ZERO),
EASY_PFS_INSTR3(0, 0,
You are quite right - also the following instruction:
{
EASY_PFS_INSTR0(MAD, SRC0C_XYZ, ONE, ZERO),
EASY_PFS_INSTR1(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, NONE,
ALL),
EASY_PFS_INSTR2(MAD, SRC0A, ONE, ZERO),
EASY_PFS_INSTR3(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, O
On Thu, 3 Feb 2005, Keith Whitwell wrote:
Rune Petersen wrote:
Vladimir Dergachev wrote:
I couldn't find a combination that makes alpha look any better and got
angry at the identical instructions which didn't do anything.
So I removed them.
I don't se any problem without these innstuctions. unles
On Thu, 03 Feb 2005 08:51:31 +, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> Rune Petersen wrote:
> > Vladimir Dergachev wrote:
> >
> >>
> >> One thing you might try is to exchange the order of arguments or do
> >> something similar. There are some comments by Nicolai on ordering of
> >> argumen
Hi!
>>
>> Good point. That's my change in non-core which hasn't been propogated
>> to
>> core. It's just a cleanup & I wouldn't have expected either version to
>> be
>> crash-prone.
>>
>> I don't think the irq handler gets much of a workout unless you
>> sync-to-vblank
>> at the moment.
>
> it m
Rune Petersen wrote:
Vladimir Dergachev wrote:
One thing you might try is to exchange the order of arguments or do
something similar. There are some comments by Nicolai on ordering of
arguments in r300_reg.h, these might reflect actual hardware limitations.
For example, I do not understand why i
Vladimir Dergachev wrote:
Would anyone know whether tnl->render_inputs is still valid when using
a vertex shader program (in particular, arbvptorus) ?
I don't think the work has been done to calculate it correctly for
vertex programs.
Keith
38 matches
Mail list logo
