the shared memory manager?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF.Net email is Sponsored by the Better Software Conference EXPO
-EAGAIN. Does the attached patch work for you?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Index: src/mesa/drivers/dri/r200/r200_texmem.c
are:
NV_texture_rectangle
ARB_texture_border_clamp
ARB_multitexture
ARB_texture_env_combine
Some kind of render-to-texture functionality (preferably framebuffer
objects) will probably be crucial, at least for compositing.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre
Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA
On Fri, 2005-08-05 at 23:09 -0500, Alan Grimes wrote:
DRM_RADEON_TEXTURE: return = -11
Actually, -11 is -EAGAIN, so the r200 driver should just call the ioctl
again. So this definitely looks like a bug in the r200 driver.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI
to PCI memory instead. Fixing that
would be a nice little project for someone who wants to get their hands
dirty with the DRM.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
are designed for privileged clients like the current DDX
drivers and thus unchecked.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF.Net
these?
The current DDX drivers.
They aren't used in the mesa tree.
So why did you change their requiring root?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote:
On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote:
They aren't used in the mesa tree.
So why did you change their requiring root?
The version of Xegl I am making does not run as root. [...]
I know. You missed my question: Why do
from entering C3? Either way, it would be very useful if you could
somehow determine exactly what the guilty bus mastering cycles do.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
On Tue, 2005-07-12 at 13:06 +0200, Sander Sweers wrote:
Well xscreensaver is horrible to do any tests with, I never get above
the 25 fps :(
Which hack(s) are you trying, and are you passing -delay 0?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software
when the DRM loads it attempts to setup an mtrr at 0, which of
course clashes with the mtrr for my RAM
I guess with a PCIe card, it shouldn't set up an MTRR for the AGP
aperture in the first place?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software
screensaver code. Search the list
archives if you want to know more.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF.Net email
On Fri, 2005-07-01 at 03:24 +0300, Aapo Tahkola wrote:
On Sun, 26 Jun 2005 23:48:11 -0400
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote:
On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote:
Disagree also about axing the comment - its
remember agreeing to that. That
we may not be able to prevent all such cases doesn't mean we shouldn't
prevent the ones we can.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
commands, using specialized
ioctls?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF.Net email is sponsored by: Discover Easy Linux
On Wed, 2005-06-08 at 00:01 -0400, Jon Smirl wrote:
On 6/7/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Tue, 2005-06-07 at 15:48 -0400, Jon Smirl wrote:
Am I right in this interpretation? First I need to get the
bus/device/func of the card, then I need to tell this to the driver
On Sat, 2005-05-28 at 20:07 +1000, Nik wrote:
The folks at JOGL indicated the problem could be due to JOGL making
extensive of threads. Does that sound like a good plasce to start the
investigation, or would you suggest I just start tracing back from the
exception?
That's usually a good
On Fri, 2005-05-27 at 19:02 +0100, Alan Hourihane wrote:
Why does the mga_drv.c set DRIVER_REQUIRE_AGP when it doesn't 'require' it
if there's a PCI Matrox card ?
Couldn't we do
if (drm_device_is_agp(dev) || DRIVER_REQUIRE_AGP)
dev-agp = drm_agp_init(dev);
and
On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote:
Hi,
One more for good messure.
2048x2048 texturer are corrupted. half (1024x2048) is correct, the rest
is random data from memory.
Not being familiar with the r300 code, I can only guess, but it sounds
like the r300 driver still always
On Tue, 2005-05-24 at 23:26 +0200, Rune Petersen wrote:
Michel Dnzer wrote:
On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote:
Hi,
When experimenting with UT2004 demo I get:
DRM_RADEON_TEXTURE: return = -22
offset=0x04823000
image width=32 height=1024
blit
On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote:
I am thinking that there might be a bug where CP engine does something
funny when the ring buffer is completely full. Maybe we need to keep a
small chunk of space open so that start and end pointers are different.
WPTR == RPTR
On Mon, 2005-05-23 at 18:45 +0200, Nicolai Haehnle wrote:
It is equally likely that the lockup is caused by, say, alignment or
wraparound issues of the ring buffer.
Note that fglrx always submits commands in indirect buffers, which are
stored linearly in physical memory. We, on the other
On Wed, 2005-05-25 at 15:06 -0400, Vladimir Dergachev wrote:
On Wed, 25 May 2005, Michel [ISO-8859-1] Dnzer wrote:
On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote:
I am thinking that there might be a bug where CP engine does something
funny when the ring buffer is
On Wed, 2005-05-25 at 16:11 -0400, Vladimir Dergachev wrote:
WPTR == RPTR means the ring is empty, if you mean that. The DRM handles
that though, unless you made r300 specific changes to the ring handling.
(I don't think that RBBM_STATUS would indicate the CP being busy in that
case,
On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote:
Hi,
When experimenting with UT2004 demo I get:
DRM_RADEON_TEXTURE: return = -22
offset=0x04823000
image width=32 height=1024
blit width=1024 height=128 data=0xa6246200
It is random when in the game this happens. I've
On Mon, 2005-05-23 at 10:10 +0300, Aapo Tahkola wrote:
On Sun, 22 May 2005 21:00:19 +0200
Jerome Glisse [EMAIL PROTECTED] wrote:
I setup a x86 with radeon 9800 pro or xt, trying to find
why it locks. I see little improvement with option no silken
mouse can you test and tell me if it
On Sun, 2005-05-22 at 21:00 +0200, Jerome Glisse wrote:
I setup a x86 with radeon 9800 pro or xt, trying to find
why it locks. I see little improvement with option no silken
mouse can you test and tell me if it dones anythings for
you (X -nosilk).
My thought on this lockups is that it's
On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote:
1) When I move a window over a 3D rendering window the contents jumps to the
top left hand part of the display. If I move the output (say the glxgears)
window to the top left I see the output centred at the screen edge, otherwise
the
On Tue, 2005-05-03 at 15:24 +1000, Benjamin Herrenschmidt wrote:
The radeon DRM has some interesting bug that paul and I discovered to
cause all sort of problems like crashing the machine on suspend/resume
(go figure ...) etc...
dev_priv-gart_vm_start = dev_priv-fb_location
On Tue, 2005-05-03 at 10:09 +0200, Jerome Glisse wrote:
On 5/3/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Ok, I'm cross posting here because X.org is doing it wrong too. On R300,
for some reason I don't fully understand, it just goes back to the old
way of putting the FB at 0
I
On Wed, 2005-05-04 at 00:39 +1000, Benjamin Herrenschmidt wrote:
Note that with huge VRAM sizes appearing, we also want to make sure that
wheverver we put it won't overlap the 32 bits space since CONFIG_MEM_SIZE
can be huge nowadays... and if it does, put the GART just _before_ the
On Wed, 2005-05-04 at 11:41 +1000, Benjamin Herrenschmidt wrote:
Ok, here's a new patch that I'll send to Linus if you (Michel) acks it.
I use CONFIG_MEMSIZE, I don't try to max out with CONFIG_APER_SIZE since
I beleive we just don't care, and that avoids putting pressure on the
GART
On Mon, 2005-18-04 at 18:44 +0200, Geller Sandor wrote:
On Mon, 18 Apr 2005, Michel [ISO-8859-1] Dnzer wrote:
Did you post the problems you encountered?
Yes, on Mon, 14 Feb 2005. You were one of the recipients :)) There was a
thread 'OpenGL apps causes frequent system locks' on dri-devel.
On Thu, 2005-04-14 at 13:36 -0400, Jonathan Bastien-Filiatrault wrote:
I have tried the experimental r300 driver with my Radeon 9800 Pro.
The rendering speed and accuracy are simply amazing. Unfortunately, I am
getting random lockups about every five minutes. The Xorg process takes
100%
On Wed, 2005-03-16 at 15:35 -0500, Vladimir Dergachev wrote:
On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
Michel, I think we are
On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjl wrote:
I don't see the current system slowly evolving into some superb future
system with an in kernel memory manager. The current APIs just have too
many limitations. I think the memory manager must be the foundation of
everything and after
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote:
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to system memory, using the swapper will no
longer work. I don't see any other solution that having the CPU perform
the byte
On Thu, 2005-03-17 at 10:28 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-16 at 16:00 -0500, Michel Dnzer wrote:
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote:
One thing just popped to my head though. If in the future we are going to
allow graphics cards to render to
On Wed, 2005-03-16 at 17:46 -0500, Vladimir Dergachev wrote:
So can we be sure that one can do arbitrary INREG() on Radeons without
fear of lockup ?
I think so, in general.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
On Tue, 2005-03-15 at 12:30 +0100, Roland Scheidegger wrote:
Ville Syrjl wrote:
I think that making the assumption that all memory is preserved when
the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and -
On Tue, 2005-03-15 at 11:37 -0600, D. Hageman wrote:
I added to the Installation instructions:
Packages are available for Linux distributions utilizing RPM package
management in the Download section. We currently do not have Debian
packages available. If you are interested in the role of
On Tue, 2005-03-15 at 22:10 +0100, Richard Stellingwerff wrote:
I just installed the latest snapshot of the radeon DRI driver from
http://dri.freedesktop.org/snapshots/radeon-20050314-linux.i386.tar.bz2.
Installation went without problems, but direct rendering is disabled.
output of
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
This would mean that on r300 this fix is not needed, but rv350 locks up
without it.
In that case perhaps it makes sense to only wait for idle on
On Wed, 2005-03-16 at 10:33 +1100, Benjamin Herrenschmidt wrote:
Now, I agree that cutting the vram in half, and reserving both halves
to the offscreen needs to each head may help avoiding mode switch on
one head busting things used by whoever works on the second head, but
I'm not sure that
On Wed, 2005-03-16 at 00:17 +0100, Richard Stellingwerff wrote:
Anyway, the driver works, but it's VERY unstable for me.
If you're using MergedFB (which includes clone mode), see the current
thread '[r200] Lockups...'.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
On Tue, 2005-03-15 at 20:07 -0500, Vladimir Dergachev wrote:
On Tue, 15 Mar 2005, Vladimir Dergachev wrote:
My understanding was that for
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think this
function will be
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer wrote:
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
And finally, I want to blank the screen (using the accel engine) before
setting the new mode, so
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
On Tue, 2005-03-15 at 08:52 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2005-03-14 at 11:20 -0500, Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer wrote:
On Sun, 2005-03-13 at 17:43 +1100, Benjamin
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an SMP system). Other
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
Be that as it may, it remains a fact that such a change would break
existing installations...
I think that mode setting and memory allocation should be separated. X
will always reserve enough video RAM for the largest
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
And finally, I want to blank the screen (using the accel engine) before
setting the new mode, so that we come out clean of the mode setting
(without ugly artifact), and I will probably clean both fb's (simpler).
That would
On Sat, 2005-03-12 at 14:30 -0500, Adam K Kirchhoff wrote:
When trying neverputt:
[drm] Loading R200 Microcode
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0
owner da0fcd80 d2809b80
Weird, does this only happen when running a 3D client, or also without?
On Sat, 2005-03-12 at 23:52 +0100, Jerome Glisse wrote:
Sounds like there could be problems with Paul's texture upload changes.
Paul patch doesn't make its way to 2.6.11 ? Because Adam says he
gots the same prob with 2.6.11 right ?
You removed the context this was referring to:
[...] I
On Fri, 2005-03-11 at 23:02 +1100, Paul Mackerras wrote:
Michel Dnzer writes:
The difference is that for a hostdata blit, the CP writes the data to
the hostdata registers synchronously, whereas with your change, the 2D
engine will fetch the data asynchronously.
What do you think of
[ Please don't top-post ]
On Wed, 2005-03-09 at 10:38 +0100, Jerome Glisse wrote:
I don't think this will change anything for x86 setup.
Yeah, the real question is whether it breaks pre-R300 chips on big
endian machines, but it looks fine to me.
Moreover could this change also affect way X
On Thu, 2005-03-10 at 09:10 +1100, Paul Mackerras wrote:
Michel Dnzer writes:
Nice. It might also be interesting to experiment with copying the
texture data into the ring itself instead of into indirect buffers (and
use type 3 NOP packets to have the CP skip it), if someone feels so
On Wed, 2005-02-16 at 21:16 +0100, Dieter Ntzel wrote:
#0 _tnl_build_vertices (ctx=0x8060928, start=0, end=0, newinputs=0)
at tnl/t_vertex.c:1379
1379 a[j].inputstride = vptr-stride;
(gdb) list
1374 const GLuint count = vtx-attr_count;
1375 GLuint j;
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you
can see
On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote:
if ( (info-ChipFamily == CHIP_FAMILY_R300) ||
(info-ChipFamily == CHIP_FAMILY_R350) ||
- (info-ChipFamily == CHIP_FAMILY_RV350) )
+ (info-ChipFamily == CHIP_FAMILY_RV350) ||
+ (info-ChipFamily ==
On Fri, 2005-03-04 at 13:53 -0500, Vladimir Dergachev wrote:
On Fri, 4 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote:
if ( (info-ChipFamily == CHIP_FAMILY_R300) ||
(info-ChipFamily == CHIP_FAMILY_R350) ||
-
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you
can see that there are problems with light reflection in those places
where there's ice (for
On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote:
I think long term though, a better solution would be to get rid of
mergedfb and handle each head separately but just change the 2d/3d
engines offsets depending on which head you are rendering to. then
you wouldn't have to worry about
[ Please don't follow up just to me privately ]
On Thu, 2005-02-24 at 14:26 +0100, Marcello Maggioni wrote:
On Wed, 23 Feb 2005 23:02:37 -0500, Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2005-02-23 at 20:50 +0100, Marcello Maggioni wrote:
I've a problem with lastest DRI (from CVS)
On Fri, 2005-02-25 at 19:08 +0200, Boris Peterbarg wrote:
I've noticed something weird about the flickering I get with r300.
Normally any 3d program or game flicker when I run them.
I tried running a windows game under the latest wine - Babylon 5: I've
Found Her (http://ifh.firstones.com).
On Wed, 2005-02-23 at 20:50 +0100, Marcello Maggioni wrote:
I've a problem with lastest DRI (from CVS) drivers and Xscreensavers
that use OpenGL.
I've tried nearly all of them , from Bubble 3D to Rubik Cube all
these simply flicker like hell when are executed .
If you're running them
On Tue, 2005-02-15 at 22:36 +, Chris Rankin wrote:
By the power of my serial console, here is what gdb
says about my crazy celestia-1.3.2 process:
Just one of many possible symptoms of a GPU lockup I'm afraid. Does
commenting out Option AGPMode make a difference?
--
Earthling Michel
On Tue, 2005-02-15 at 11:47 +, Dave Airlie wrote:
I'm thinking about how these could be used in Mesa drivers? would I be
correct in thinking the fallbacks would mess up as the Mesa copy of the
texture wouldn't be the same as what the card would be using?
I'm not sure that the
On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote:
AFAIK, the lockups are due to interference between 2d packets from Xserver
and 3d packets from the driver. Somehow mouse movement provokes it,
possibly when the cursor shape changes on crossing window boundaries..
It is not
On Tue, 2005-02-15 at 11:36 -0500, Vladimir Dergachev wrote:
On Tue, 15 Feb 2005, Michel [ISO-8859-1] Dnzer wrote:
On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote:
AFAIK, the lockups are due to interference between 2d packets from Xserver
and 3d packets from the driver.
On Tue, 2005-02-15 at 12:08 -0500, Vladimir Dergachev wrote:
Have you tried idling the engine before uploading the cursor data?
I haven't played with that part of 2d driver, but shouldn't it do this
already as all ATI cards are touchy about framebuffer access while
the graphics engine is
On Mon, 2005-02-14 at 20:06 +0100, Dieter Ntzel wrote:
dmesg show this:
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 2x mode
agpgart: Putting AGP V2 device at :01:05.0 into 2x mode
glxinfo
OpenGL vendor string:
On Mon, 2005-02-14 at 22:27 +, Chris Rankin wrote:
I have a Radeon 9200 AGP card, and have manually
compiled XOrg 6.8.2 for my dual P4 Xeon (with
hyperthreading enabled) Linux 2.6.10 system. However,
I am finding that the Xserver locks up when I run
celestia 1.3.2 with hardware
On Sun, 2005-02-13 at 18:38 +0100, Felix Khling wrote:
r200_screen.c: In function `r200CreateScreen':
r200_screen.c:407: error: `addr' undeclared (first use in this function)
Whoops, my bad, should be fixed now. I wonder how that built for me...
--
Earthling Michel Dnzer | Debian
On Mon, 2005-02-14 at 09:07 +1100, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-12 at 23:56 -0500, Michel Dnzer wrote:
On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote:
Those are still incorrect as they totally lack memory barriers...
INREG() doesn't (or does it?),
On Sat, 2005-02-12 at 13:03 +0100, Jerome Glisse wrote:
Could anyone apply this patch if it looks good.
This correct the problem many ppc user have
using the Mesa-dri cvs which does not do the
swapping for bendian.
The code came from Michel, i am only doing
the patch and the #ifdef
On Sat, 2005-02-12 at 21:00 +0100, Jerome Glisse wrote:
Yes as a hack we could redefine this.
Please, let's get a proper fix into Mesa instead. Have you tried my
cleaned up patch?
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote:
Those are still incorrect as they totally lack memory barriers...
INREG() doesn't (or does it?), and it's the only one used by the 3D
drivers.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre
On Wed, 2005-02-09 at 02:32 -0500, Vladimir Dergachev wrote:
On Tue, 8 Feb 2005, Michel [ISO-8859-1] Dnzer wrote:
On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote:
Could someone with knowledge of r200_dri explain how vertex buffer
uploads are put into framebuffer memory on r200?
On Tue, 2005-02-08 at 16:57 +0500, Alexander E. Patrakov wrote:
On Sat Nov 27 22:47:59 2004 UTC, there was a big commit into Mesa CVS by
brianp, with the following comment:
Remove _mesa_ResizeBuffersMESA() call from _mesa_set_viewport().
Now, the driver's Viewport routine should call
On Mon, 2005-02-07 at 13:40 +0100, Geller Sandor wrote:
Is there any way I can help to track down the problem(s)? My machine
doesn't have network connection, so I can use only scripts which run in
the background. With expect and gdb maybe it is possible to get at least a
backtrace from my
On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote:
Could someone with knowledge of r200_dri explain how vertex buffer
uploads are put into framebuffer memory on r200?
AFAIK they aren't, the only data the radeon and r200 drivers upload to
the framebuffer is textures.
--
Earthling Michel
On Tue, 2005-02-08 at 00:12 +0500, Dimitry Naldayev wrote:
Michel Dnzer [EMAIL PROTECTED] writes:
On Sun, 2005-02-06 at 19:32 +0500, Dimitry Naldayev wrote:
Michel Dnzer [EMAIL PROTECTED] writes:
I am about the X server and drm module --- what happens when we do vt
switch? How this
On Tue, 2005-02-08 at 02:30 +, Dave Airlie wrote:
I fully support the idea of enabling gart texturing on the r200 driver. If
the old client texturing code can be kept around as an X config option, so
much the better, but it shouldn't stand in the way of gart texturing given
the
On Sun, 2005-02-06 at 19:32 +0500, Dimitry Naldayev wrote:
Michel Dnzer [EMAIL PROTECTED] writes:
FWIW, the infamous radeon DRI reinit patch is at
http://penguinppc.org/~daenzer/DRI/radeon-reinit.diff
look like it is realy not best way do things right...
so couple of questions:
1)
On Sun, 2005-02-06 at 19:29 +0100, Richard Stellingwerff wrote:
When using OpenGL applications I get frequent X crashes as well as
complete system locks. They happen totally random.
My hardware is an Ati Radeon Mobility 9200 M9+.
I'm using archlinux 0.7 with X.org 6.8.1 using the radeon
On Fri, 2005-02-04 at 00:29 +, Armin Krieg wrote:
I'm using a Radeon 9600XT and there are no error-messages in syslog
and i hope i can give also another bug-report, although I think its a problem
with the new dri-code...
I'm using a cvs-snapshot of x.org and with the newer kernels
On Wed, 2005-02-02 at 22:18 +0100, Felix Khling wrote:
[...] only one display can use the DRM at the same time. There was
a patch for the Radeon driver once that solved this problem by
reinitializing the DRM on VT switches, but the Savage driver doesn't
support this now.
Is
On Mon, 2005-01-31 at 13:22 +0100, Thomas Hellstrm wrote:
The thing is that I don't see this with the old drm (Running for a
reasonable amount of time), but on the other hand I can't see what in drm
CVS could be causing this.
Could be
On Fri, 2005-01-28 at 12:50 +0100, Amir Bukhari wrote:
Indeed, it's our driver that disables the DRI if Composite is enabled,
not the DRI in general. I expect that to stay the same until the two are
properly integrated with each other (but it's not my decision to make).
If some could
On Thu, 2005-01-27 at 19:06 +0100, Jerome Glisse wrote:
So no hope for using MULTIBLT ? I haven't looked to the source but
i suppose dri do not use agp space to upload texture but a dma buffer.
Yes, but that's not set in stone, so as I said, it might be a
possibility for OpenGL texture
On Wed, 2005-01-26 at 13:36 -0500, Vladimir Dergachev wrote:
Correction - I looked at the source and we compile the texture data as a
string, so no conversion is being done.
Define 'compiling as a string', but it sounds to me like it does
implicitly produce the same byte order regardless of
On Wed, 2005-01-26 at 23:10 -0500, Vladimir Dergachev wrote:
I meant that RGBA picture is represented as an unsigned char
array. So byte 0 is always R, byte 1 G, and so on - irrespectively of the
architecture.
There is however an issue of whether conversion is being done when doing
On Tue, 2005-01-25 at 18:39 +0100, Roland Scheidegger wrote:
The attached patch should finally fix the mergedfb + pageflip issue. It
should also fix another minor problem when switching resolutions and a
3d client is active. Guess it's a bit hackish, but it works for my faked
mergedfb
On Mon, 2005-01-24 at 14:24 +0100, Jerome Glisse wrote:
On Sun, 23 Jan 2005 15:54:26 -0500, Michel Dnzer [EMAIL PROTECTED] wrote:
On Sun, 2005-01-23 at 12:31 +0100, Jerome Glisse wrote:
I was wondering what was the differences between using hostdata_blt
bitblt_multi. One faster than
On Mon, 2005-01-24 at 22:24 +0100, Roland Scheidegger wrote:
Alex Deucher wrote:
pageflipping still doesn't work with mergedfb.
Is that with Roland's separate patch for this applied as well?
yes. I doesn't work with various attempts I made as well.
I've done some tests too with faked
On Sun, 2005-01-23 at 12:31 +0100, Jerome Glisse wrote:
I was wondering what was the differences between using hostdata_blt
bitblt_multi. One faster than other ? Do not use same path for reading
data ?
Indeed, the BITBLT_MULTI type 3 packet only allows blits within the
GPU's address space,
On Sun, 2005-01-23 at 18:33 -0500, Alex Deucher wrote:
On Fri, 21 Jan 2005 21:03:06 +0100, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Ok, new version is up here:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm9.diff
401 - 500 of 1646 matches
Mail list logo
