On Fri, 18 Feb 2005 20:06:53 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
I think I found the cause of lockups in VB mode - they were due to cursor
updating function in radeon_mergedfb.c calling OUTREGP() which in turn
called INREG.
When silken mouse is enabled this function
Vladimir Dergachev schrieb:
I think I found the cause of lockups in VB mode - they were due to
cursor updating function in radeon_mergedfb.c calling OUTREGP() which in
turn called INREG.
When silken mouse is enabled this function could be called at any time
which would do *bad* things when CP
Roland Scheidegger wrote:
Since people have asked for it, I decided I'd give it a try...
So here it is, a unified radeon driver (no not r300, only r100 and r200).
http://homepage.hispeed.ch/rscheidegger/dri_experimental/ati_radeon.tar.bz2
exectuable generated will be called radeon_dri.so, for
Also, I have no idea why the code in radeon_cursor.c that writes images
directly into framebuffer memory works - according to the manual any
writes into framebuffer while GUI is active should cause a hard lock.
However, I could not produce any lockups with it, and so left it as is.
Does using the
The fix of putting RADEONWaitForIdleMMIO() works fine on my setup.
I have *no* idea why this worked with immediate mode at all and why no
issues were reported by R200 and Radeon users (well, I only looked through
the mailing lists, perhaps there is something on bugzilla but I don't know
how to
Vladimir Dergachev schrieb:
Interesting :) Could you try this with latest X.org source ?
Sorry, but I probably won't find much time. I'll be away from the
rv250 during the next week. Next month I'll have to write some exams,
while at the beginning of april there are oral exams. I hope to
find more
On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
Also, I have no idea why the code in radeon_cursor.c that writes images
directly into framebuffer memory works - according to the manual any
writes into framebuffer while GUI is active should cause a hard
Nicolai Haehnle wrote:
On Saturday 19 February 2005 01:05, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
Please, everybody, get the latest CVS (anonymous will take some time to
catch up...) and test vertex buffer mode with it (go to r300_run_render()
in r300_render.c and change the #if
On Sat, 19 Feb 2005, Alex Deucher wrote:
On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
Also, I have no idea why the code in radeon_cursor.c that writes images
directly into framebuffer memory works - according to the manual any
writes into framebuffer while
Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
On Saturday 19 February 2005 01:05, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
Please, everybody, get the latest CVS (anonymous will take some
time to catch up...) and test vertex buffer mode with it (go to
r300_run_render() 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=2578
Summary: [radeon] Rendering glitches in unreal tournament 2003
Hi,
I wanted to know how i can ask mesa to
give me the texture in a specified order.
i.e. actually mesa give me texture in
RGBA_REV
while i want it in RGBA
I have tried to have by specifing
GL_UNSIGNED_INT_8_8_8_8_REV
to the format parameter of glTexImage2D
This effectively leads mesa
Jerome Glisse wrote:
Hi,
I wanted to know how i can ask mesa to
give me the texture in a specified order.
i.e. actually mesa give me texture in
RGBA_REV
while i want it in RGBA
I have tried to have by specifing
GL_UNSIGNED_INT_8_8_8_8_REV
to the format parameter of glTexImage2D
This
in the driver (r300) i really would like
to test all texture format, so is there
a way to ask mesa to send me texture
in a specific order (REV or not)
No. The format parameter describes the incoming format of the user's
texture image. It may or may not have any bearing on which hardware format
No. The format parameter describes the incoming format of the
user's texture image. It may or may not have any bearing on which
hardware format is chosen by the driver. More typically, the
internalFormat parameter is used by the driver to choose the
hardware texture format.
I am standing
Vladimir Dergachev wrote:
Adam
Same lockups with tuxracer, but it happened much quicker. You can
view the full debug output from tuxracer at:
http://go.visualtech.com/adam/tuxracer.txt
It's about 6 megs in size.
I suggest you gzip it next time - this should work exceedingly well
with log
: [EMAIL PROTECTED]
Gentoo 2004.3, 2.6.10 kernel, XOrg-6.8.2
(using the in-kernel DRM from Linux 2.6.10, and the radeon driver from
XOrg-6.8.2)
Also reproduced w/ Radeon DRI snapshot 20050219
(http://dri.freedesktop.org/snapshots/radeon-20050219-linux.i386.tar.bz2)
(using DRM kernel module from
Jerome Glisse wrote:
No. The format parameter describes the incoming format of the
user's texture image. It may or may not have any bearing on which
hardware format is chosen by the driver. More typically, the
internalFormat parameter is used by the driver to choose the
hardware texture format.
Am Samstag, den 19.02.2005, 01:11 +0100 schrieb Nicolai Haehnle:
Hi,
On Saturday 19 February 2005 00:46, Roland Scheidegger wrote:
There is some problem with driconf, it seems to have some problems
because the driver's name (radeon) does not match what it expects
(r200). Likewise, I
Vladimir Dergachev wrote:
in the driver (r300) i really would like
to test all texture format, so is there
a way to ask mesa to send me texture
in a specific order (REV or not)
No. The format parameter describes the incoming format of the
user's texture image. It may or may not have any
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote:
Vladimir Dergachev schrieb:
I think I found the cause of lockups in VB mode - they were due to
cursor updating function in radeon_mergedfb.c calling OUTREGP() which in
turn called INREG.
When silken mouse is enabled
On Saturday 19 February 2005 02:06, Vladimir Dergachev wrote:
I think I found the cause of lockups in VB mode - they were due to cursor
updating function in radeon_mergedfb.c calling OUTREGP() which in turn
called INREG.
When silken mouse is enabled this function could be called at any
No on has tried getting XGL running on top of mesa-solo. I don't know
of any obvious reason why it shouldn't work other than no one has
tried doing it yet. First check out that your mga mesa-solo is
running, there are test programs in the mesa tree for this. Then try
to get XGL running on
The reason I am asking is that R300 appears to support all (or almost all)
GL texture formats and it would not be too difficult to add this support,
but we are using R200 switch() due to lack of understanding of Mesa-driver
interface.
Well, even if the hardware does support all the present Mesa
Also, I have no idea why the code in radeon_cursor.c that writes images
directly into framebuffer memory works - according to the manual any
writes into framebuffer while GUI is active should cause a hard lock.
However, I could not produce any lockups with it, and so left it as is.
I can see no
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the above are about 5 days old, doesn't have
Vladimir
On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote:
[...]
For example, I am often seeing about 2-sec delay upon the start of a GL
app (all 2d updates are frozen). The delay always happens upon the first
GL context after a cold reboot, and it is often not present on successive
On Sat, 19 Feb 2005, Vladimir Dergachev wrote:
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the
On Sat, 19 Feb 2005, Eric Anholt wrote:
On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote:
[...]
For example, I am often seeing about 2-sec delay upon the start of a GL
app (all 2d updates are frozen). The delay always happens upon the first
GL context after a cold reboot, and it is
On Sat, 2005-02-19 at 23:25 -0500, Vladimir Dergachev wrote:
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
30 matches
Mail list logo
