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 k
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 ofte
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 ab
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
> la
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
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 dif
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
> 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
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
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 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 parameter describes the incoming format of the
user's texture image. It may or may not have any bearing on wh
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). Likewi
Jerome Glisse wrote:
No. The 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
parameter is used by the driver to choose the
hardware texture format.
I am standing from
dBy: [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 f
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 file
> No. The 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
> parameter is used by the driver to choose the
> hardware texture format.
I am standing from the driver
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 parameter describes the incoming format of the user's
texture image. It may or may not have any bearing on which hardware format
is cho
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 effec
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
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
P
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 r300_render
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 whil
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 s
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
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
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 u
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 o
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 r20
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 e
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 func
30 matches
Mail list logo
