On Sun, 2005-01-23 at 20:42 -0500, Alex Deucher wrote:
Both viewports end up at zero as usual.
That doesn't make sense, at least CRTC2 should always have worked
correctly. I suspect something's wrong on your end, unless you're using
the *-core DRM maybe, and this was broken there
On Fri, 2005-01-21 at 21:03 +0100, Roland Scheidegger wrote:
Ok, new version is up here:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm9.diff
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx9.diff
On Sun, 2005-01-23 at 02:48 +0100, Roland Scheidegger wrote:
You're right though it might not be a very good idea to support depth
moves corretly only sometimes. Guess it would in fact be better to not
support them at all, Keith seemed to be perfectly happy with that
solution. Will remove
On Thu, 2005-01-20 at 12:49 +0100, Jacek Rosik wrote:
Radeon and R200 drivers report GL_MAX_VIEWPORT_DIMS=4096, 4096, but I
think that hardware can maximally suport 2048, 2048. Anyway I don't
think current drivers don't even support 1, 1 if window will be placed
further from top left corner
On Wed, 2005-01-19 at 17:30 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
Also, if doing that in the drm, we'd need to mess with
OFFSET_CNTL there too (i.e. messy calculation or another field
in the sarea).
You mean CRTC_OFFSET? I'm not sure the calculation is that big an
On Thu, 2005-01-20 at 03:03 +0100, Stephane Marchesin wrote:
Michel Dnzer wrote:
What happened to Stephane's surface allocator, BTW? If you just whack
the surface registers directly from the X server, it becomes hard if not
impossible to introduce such an allocator, at least for the surfaces
On Thu, 2005-01-20 at 20:09 +0100, Jacek Rosik wrote:
Anyway I don't think that these groups would be multiple of 2048. I
can't set offset to any value, it must be aligned as i wrote before. So
this would be something around 2040. Or, am I missing something?
The alignment only matters for
On Wed, 2005-01-19 at 13:32 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Tue, 2005-01-18 at 20:43 +0100, Roland Scheidegger wrote:
The DRM could update the register in the vblank interrupt
handler?
[...]
How would you do that in-kernel? There is vblank
On Wed, 2005-01-19 at 23:49 +0100, Amir Bukhari wrote:
On Wednesday 19 January 2005 17:29, Amir Bukhari wrote:
Hallo,
Our users of Looking Glass 3D Desktop have a problem getting DRI to work
with LG3D. DRI is disabled when Composite Extension enabled. Is There
any
way to enable
On Tue, 2005-01-18 at 08:28 +, Dave Airlie wrote:
I have an application that has been running for 2-3 days no worries
with vblank_mode=0, but of course chews CPU and tears the screen, I
recently started running it with vblank_mode=2 or 3 and it hangs
in the glXSwapBuffers after a
On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
Speaking of mergedfb and page flipping: Is it really necessary to add
a new private SAREA field and a corresponding setparam? Isn't it
possible to set the generic SAREA fields as the DRM expects them, to
On Tue, 2005-01-18 at 16:31 +0100, Roland Scheidegger wrote:
Alex Deucher wrote:
Actually DRIAdjustframe() and friends in dri.c may still be the
problem. it does some wrapping of the adjustframe() functions and
calls them, perhaps incorrectly for mergedfb. I could be wrong though
I
On Tue, 2005-01-18 at 20:43 +0100, Roland Scheidegger wrote:
The DRM could update the register in the vblank interrupt handler?
[...]
How would you do that in-kernel? There is vblank interrupt related stuff
(radeon_driver_vblank_wait for instance), but that only is called when a
user has
On Mon, 2005-01-17 at 21:34 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
The location of the framebuffer as seen by the
GPU needs is defined by MC_FB_LOCATION. All current components have
fields named along the lines
On Tue, 2005-01-18 at 14:22 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2005-01-14 at 12:23 -0500, Michel Dnzer wrote:
On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
Anyway i wanted to ask mesa folks how to make a real
proper patch. The fact is that INREG OUTREG in
On Sat, 2005-01-15 at 18:55 +0100, Jerome Glisse wrote:
On Sat, 15 Jan 2005 12:22:24 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
#define R300_SURFACE_CNTL 0xb00
# define R300_SURFACE_TRANSLATION_DISABLE (18) /* this is
default */
# define
On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
One question I still have though is regarding to the surface setup, I'm
actually not convinced the addresses are correct in all cases, because I
don't understand how all that address translation stuff works. So
currently the
On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
Anyway i wanted to ask mesa folks how to make a real
proper patch. The fact is that INREG OUTREG in
server/radeon_macros.h have to do endian swapping.
Moreover the swapping is only needed for r300, isn't it ?
So do we need to have our
On Fri, 2005-01-14 at 18:48 +0100, Jerome Glisse wrote:
On Fri, 14 Jan 2005 12:23:50 -0500, Michel Dnzer [EMAIL PROTECTED] wrote:
On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
Anyway i wanted to ask mesa folks how to make a real
proper patch. The fact is that INREG OUTREG in
On Fri, 2005-01-14 at 19:51 +0100, Jerome Glisse wrote:
I will try your patch but i bet it works.
I am agree too that this should not be in driver specifique but how to
handle the r300 case properly on ppc ?
There's no 'r300 case'. This will be the same for all Radeons and
On Fri, 2005-01-14 at 16:47 +0100, Roland Scheidegger wrote:
1) ignore the problem. This might be ok if the ddx is only incompatible
when a certain option is enabled, as long as it stays off by default
maybe (i.e. user has enabled the option, so assume he knows what he's
doing and he can
On Wed, 2005-01-12 at 00:18 +0100, Roland Scheidegger wrote:
Alex Deucher wrote:
How would you do that? I can't see a way at all how ddx would
reject a dri client.
By making the initialization fail, e.g.
Do you have some pointers how you'd do that? All code I see for
initialization is
On Mon, 2004-12-27 at 09:26 -0500, Keith Conger wrote:
Ok I changed to 24 can't remember why I bumped it down to 16 in the
first place. Also comment out the Option you had me add the artifacts do
not show.
Hmm, sounds like the host data byte swapping doesn't work via the CP for
some
On Sun, 2004-12-12 at 22:39 +0100, Stephane Marchesin wrote:
Michel Dnzer wrote:
+typedef struct drm_radeon_surface_alloc {
+ int lower;
+ int upper;
+ int flags;
+} drm_radeon_surface_alloc_t;
+
+typedef struct drm_radeon_surface_free {
+ int lower;
+}
On Sun, 2004-12-12 at 14:52 +0100, Stephane Marchesin wrote:
Here is my second try at the surface ioctl.
Does everything look correct ?
Looks like you've made good progress.
Index: shared/radeon_drm.h
===
RCS file:
On Wed, 2004-12-08 at 08:53 -0800, Daniel Sperka wrote:
I am using mesa linux-solo and radeonfb (miniglx). My application
requires strict phase-locking with the video refresh rate. I can achieve
this without page flipping, but the back-to-front buffer copy takes too
long and I get a tear.
On Wed, 2004-12-08 at 02:54 +0100, Stephane Marchesin wrote:
The small attached patch adds a new drm ioctl to do surface
allocation/deallocation on the radeon.
[...]
Any comments ? I'ts untested, but that's my first ioctl, so I wanted
feedback (both on the idea and the implementation)
On Mon, 2004-11-22 at 22:26 +, Dave Airlie wrote:
Hi all,
I'm just wondering how much testing anyone has done on the Radeon
M7/7500 and vblanks,
IIRC that was what I had when I originally wrote the wait for vblank
code, but it's changed a lot since then.
I have an application that
On Sat, 2004-11-20 at 20:22 -0600, Kevin O'Brien wrote:
On Fri, 2004-11-19 at 11:17, Michel Dnzer wrote:
On Fri, 2004-11-19 at 00:44 -0600, Kevin O'Brien wrote:
On Thu, 2004-11-18 at 03:57, Felix Khling wrote:
Am Do, den 18.11.2004 schrieb Kevin O'Brien um 8:03:
Page flipping
On Sat, 2004-11-20 at 21:30 +0100, Jacek Rosik wrote:
Dnia 19-11-2004, pi o godzinie 12:24 -0500, Michel Dnzer napisa(a):
On Fri, 2004-11-19 at 12:51 +0100, Jacek Rosik wrote:
For now I would also vote for #2. This could help some other things (eg.
GLcore could render directly into
On Fri, 2004-11-19 at 00:44 -0600, Kevin O'Brien wrote:
On Thu, 2004-11-18 at 03:57, Felix Khling wrote:
Am Do, den 18.11.2004 schrieb Kevin O'Brien um 8:03:
There is a problem in the radeon driver WRT to waiting for the refresh.
The driver can wait for the refresh but there is no
On Fri, 2004-11-19 at 12:51 +0100, Jacek Rosik wrote:
Am Fr, den 19.11.2004 schrieb Keith Whitwell um 12:14:
1) Do all drawing three times, avoiding the rectangle-blits and
possible
corruption.
or
2) Make the X server do its drawing to the current frontbuffer (rather
On Fri, 2004-11-19 at 12:17 -0500, Michel Dnzer wrote:
On Fri, 2004-11-19 at 00:44 -0600, Kevin O'Brien wrote:
Is there a way to ensure the Radeon blits from top to bottom?
Sure, by setting the
Whoops. Not only did you possibly get two copies of my post, I also put
my comments in the
On Sat, 2004-11-06 at 12:25 +0100, Nicolai Haehnle wrote:
Okay, the new syslog has all the debug info. I notice the following line:
Nov 7 07:37:58 disoft-dc [drm:radeon_cp_init_ring_buffer] writeback test
failed
The Radeon DRM source code has a comment indicating that writeback doesn't
On Sat, 2004-11-06 at 19:07 +0100, Jacek Popawski wrote:
2 days ago, after CVS update,
Which tree of which CVS repository?
I realized I can't get accelerated rendering.
(II) RADEON(0): Direct rendering enabled
but:
OpenGL renderer string: Mesa GLX Indirect
This means the problem is
On Wed, 2004-11-03 at 14:55 +0100, Stephane Marchesin wrote:
Michel Dnzer wrote:
Can this really be a per-context option, considering that the depth
buffer is shared by all contexts?
No. Where do you put global options ?
In the X driver. And you'll have to deal with clients that don't
On Wed, 2004-11-03 at 12:42 -0500, Alex Deucher wrote:
On Tue, 02 Nov 2004 16:17:58 -0800, Daniel J. Michael [EMAIL PROTECTED] wrote:
I am having a problem unrelated to the new patches. Some time recently
xv has started being really screwy (black and white except for
splotches that are
On Tue, 2004-11-02 at 02:11 +0100, Stephane Marchesin wrote:
Index: src/mesa/drivers/dri/r200/r200_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.c,v
retrieving revision 1.33
diff -u -r1.33
On Mon, 2004-11-01 at 14:21 +0100, Thomas Hellstrm wrote:
Hmm, correct me If I'm wrong, but after a brief check in the code, it
seems like the current _DRM_LOCK_IS_HELD() used in dma buffer
submission IOCTLS just checks that the lock is indeed held, but not if
it is held by the current
On Thu, 2004-10-14 at 12:29 +0200, Thomas Hellstrm wrote:
is DRM_WRITEMEMORYBARRIER() the right way to make sure data has been
flushed to AGP memory before firing it off to the DMA engine?
I think so, assuming DRM_WRITEMEMORYBARRIER boils down to an instruction
with the LOCK prefix. This is
On Fri, 2004-10-15 at 15:16 -0700, Eric Anholt wrote:
On Fri, 2004-10-15 at 14:55, Michel Dnzer wrote:
On Thu, 2004-10-14 at 12:29 +0200, Thomas Hellstrm wrote:
is DRM_WRITEMEMORYBARRIER() the right way to make sure data has been
flushed to AGP memory before firing it off to the DMA
On Wed, 2004-10-13 at 10:27 -0400, Vladimir Dergachev wrote:
On Wed, 13 Oct 2004, Benjamin Herrenschmidt wrote:
On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote:
Just to check off the obvious, are you running a recent kernel with (I
assume framebuffer) ? It could be that the
On Wed, 2004-10-13 at 19:42 +0200, Felix Khling wrote:
Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
I just changed DRM to alternative between zero and POLLIN This
will make the DRM poll() function work like the kernel expects it to
and still work with existing X servers. Can
On Wed, 2004-10-13 at 09:07 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote:
Just to check off the obvious, are you running a recent kernel with (I
assume framebuffer) ? It could be that the default might have changed to
configure the apertures
On Mon, 2004-10-11 at 18:37 -0700, Ian Romanick wrote:
I was trying to test the latest version of my ReadPixels work to make
sure I didn't break anything on big-endian. However, it seems someone
beat me to it in the Rage128 driver. :) In a nutshell, I can get one
frame of gears, and then
On Mon, 2004-09-13 at 10:52 -0400, Vladimir Dergachev wrote:
So, as Jon rightly points out the multiple drivers scheme only makes
sense in the current usage patter - you either use X or framebuffer, never
both at the same time and you consider a few seconds per switch normal.
You are
On Mon, 2004-09-13 at 02:05 -0400, Alex Deucher wrote:
On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't please Jon too much as he can see where the potential
ineffecienes with saving/restore card state on driver swap are, especailly
on running fbcon
On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't please Jon too much as he
On Sat, 2004-09-11 at 06:19 +0100, Dave Airlie wrote:
You're probably right, but it still doesn't follow that this driver must
include all the fbdev and DRM code as well. Both fbdev and the DRM could
use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
I think your
On Sat, 2004-09-11 at 13:13 -0400, Jon Smirl wrote:
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
Have you looked at the radeon X driver acceleration code in the last
couple of years?
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software
On Mon, 2004-09-06 at 07:01 -0400, Patrick McFarland wrote:
On Sun, 05 Sep 2004 20:14:43 -0400, Lee Revell [EMAIL PROTECTED] wrote:
How to fix this is a pretty hot topic now.
Yow, I didn't mean to cause such an upset. ;)
Currently, the dri cvs snapshot for 20040905 doesn't compile with
On Sat, 2004-09-04 at 16:36 -0400, Patrick McFarland wrote:
On Sat, 04 Sep 2004 14:14:55 -0400, Michel Dnzer [EMAIL PROTECTED] wrote:
What version of the DRI driver?
Where do I look for that?
Where did you get r200_dri.so from?
--
Earthling Michel Dnzer | Debian (powerpc), X and
On Sun, 2004-09-05 at 16:18 -0400, Patrick McFarland wrote:
On Sun, 05 Sep 2004 13:40:54 -0400, Michel Dnzer [EMAIL PROTECTED] wrote:
On Sun, 2004-09-05 at 04:22 -0400, Patrick McFarland wrote:
On Sun, 05 Sep 2004 02:34:59 -0400, Michel Dnzer [EMAIL PROTECTED] wrote:
Where did you
On Fri, 2004-09-03 at 17:03 +0200, Luca Zini wrote:
I have an ati 9000 on a asus a7n8x-x.
the direct rendering works well, and I can use glxgears, celestia and
some other application that need it, but a lot of games don't work.
For example when I try to start tuxracer the screen goes black
On Sat, 2004-09-04 at 05:16 -0400, Patrick McFarland wrote:
All of this was tested with a virgin 2.6.8.1 (with debug info and
frame pointers enabled) and Debian's XFree86 4.3.0.1, [...]
What version of the DRI driver?
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI
On Sun, 2004-08-29 at 11:41 +0100, Keith Whitwell wrote:
Dave Airlie wrote:
Why do you feel it will break their code? If it does, they have the option to
either update their driver to match the new code or fork off the old code
continue to use that. I wouldn't be suprised if they've already
On Fri, 2004-08-27 at 09:44 +0100, Dave Airlie wrote:
DRM_INFO(Used old pci detect: framebuffer loaded\n);
Most cards have a framebuffer... this is about framebuffer _devices_. :)
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
On Sun, 2004-08-22 at 11:40 +0200, Steffen Hein wrote:
On Sunday 22 August 2004 08:16, John Lightsey wrote:
Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768
it usually froze. glxgears gave this one 518.6 fps.
I also encountered this instability on a mobility M6
On Sun, 2004-08-22 at 01:16 -0500, John Lightsey wrote:
This is my third attempt sending this email. If sourceforge decides to let
all three copies through at once, you'll have to forgive me.
It's mostly me administrating the dri-{announce,devel,patches} at the
moment... if anyone (preferably
On Fri, 2004-08-20 at 22:59 -0700, Jon Smirl wrote:
I don't believe the DRM drivers are holding any global kernel locks
when they do wait_for_fifo. Any locks held would be internal to DRM and
can be changed if needed.
Keep in mind that any ioctl function runs with the Big Kernel Lock held.
On Thu, 2004-08-12 at 05:25 +0100, Dave Airlie wrote:
The only open issue I have is the ugliness of the
if (dev-fn_tbl.my_func)
dev-fn_tbl.my_func(x)
Using a standard no-op is a bit tricky as some fn return an int and some
void, but maybe I can use something like
On Tue, 2004-08-03 at 11:53 +0100, Dave Airlie wrote:
Okay the people who are interested in the future of the DRM seem to be
fairly evenly split between dri-devel and linux-kernel mailing lists,
I'm not going to subscribe to lk (I've been there and I quite enjoy having
a life :-), and I know
On Mon, 2004-08-02 at 22:09 +0100, Dave Jones wrote:
If subsequent DRI tree - kernel merges back out any cleanup work, it's
definitly going to be a waste of time even trying.
That can easily be avoided by doing the cleanup the right way in the
first place, i.e. in the DRI tree...
--
On Sat, 2004-07-31 at 02:56 -0400, Andrew Miklas wrote:
I'm seeing a lockup on RV250 (M9) that I thought might be related to the other
r200 problems that have been cropping up recently. These occurred using
Debian's XFree86 server (4.3.0.dfsg.1-6) and kernel 2.6.5 and 2.6.7.
What version
On Sat, 2004-07-17 at 13:47 -0700, Jon Smirl wrote:
On the other hand the fb_dri driver needs to know everything about the
framebuffer in order to work. But it can get this info by querying the
fbdev driver.
Shouldn't libGL shield the drivers from things like this?
Also, how does
On Sat, 2004-07-03 at 00:51 +0200, Dieter Ntzel wrote:
Am Freitag, 2. Juli 2004 18:55 schrieb Michel Dnzer:
On Fri, 2004-07-02 at 18:46 +0200, Dieter Ntzel wrote:
Run gltestperf on r200.
http://marc.theaimsgroup.com/?l=dri-develm=108213539614605w=2
Benchmark: 2
ZSmooth
On Fri, 2004-07-02 at 02:16 +0200, Felix Khling wrote:
[...] I havn't cvs updated in a fairly long time (could be months, don't
remember exactly). Since I wouldn't have time to deal with any problems
and I need a stable system for my work right now, I'm not going to update
before 19th
On Fri, 2004-07-02 at 09:57 +0300, Aapi Hmlinen wrote:
to, 01-07-2004 kello 21:21 -0400, Patrick McFarland kirjoitti:
Im currently using the r200 snapshots, and some programs seem to randomly
crash, taking themselves and X with them (the xserver doesnt segfault, it
wont die even if you
On Fri, 2004-07-02 at 18:46 +0200, Dieter Ntzel wrote:
Patrick McFarland schrieb:
Im currently using the r200 snapshots, and some programs seem to randomly
crash, taking themselves and X with them (the xserver doesnt segfault, it
wont die even if you kill -9 it, and I cant restart X
On Tue, 2004-06-15 at 23:33 +0200, Thomas Hellstrom wrote:
2. Have the 2d driver probe first for via_dri.so and then for
unichrome_dri.so and hand over one of the names to libGL. If the
unichrome_dri.so is the default driver, the only reason for precense
of via_dri.so is that the user
On Mon, 2004-06-14 at 21:08 -0700, Mike Mestnik wrote:
The second half of the first paragraph controdics with the first. There
are patches and the like avalible.
The second sentance is refering to the hotplug code, only needed for multi
cards(currently not suported)? Or did you mean
On Tue, 2004-06-15 at 14:11 -0700, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Mon, 2004-06-14 at 21:08 -0700, Mike Mestnik wrote:
Your right about adding interfaces into the kernel, but what's
proposed(the non hotplug stuff) is small and relitively uninteresting
On Sun, 2004-06-06 at 20:03 -0700, Mike Mestnik wrote:
I found that rb3d_coloroffset:0x1c40 gets emited in both the [1]client
and the [2]DRM.
1. At init time and 3 other places.
2. At emit state from the ctx.
I was wondering how I should procede in making changes to the way this reg
gets
On Mon, 2004-06-07 at 09:57 -0600, Brian Paul wrote:
The fact that MESA_LITTLE/BIG_ENDIAN and CPU_TO_LE32 and LE32_TO_CPU
aren't used anywhere within core Mesa (except in t_dd_vertex.h - and
that could be factored out) make me think that those macros belong
elsewhere, like in a DRI-common
On Mon, 2004-06-07 at 00:32 +0100, Dave Airlie wrote:
I've changed it to include /usr/include/endian.h rather than Xarch, it
should work...
I'm afraid that's glibc specific.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
On Mon, 2004-06-07 at 00:52 +0100, Dave Airlie wrote:
I'm afraid that's glibc specific.
If I use sys/endian.h on FreeBSD can I do the same thing?
it'll look messy but to avoid the X includes we should do it ..
#ifdef __linux__
#include endian.h
#else
#include sys/endian.h
#define
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrjl wrote:
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
expose 2D and 3D hardware acceleration
functions, allow applications (DirectFB, xservers) to query the
available acceleration methods,
I disagree.
This part of
On Sat, 2004-06-05 at 14:09 +0300, Ville Syrjl wrote:
On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel Dnzer wrote:
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrjl wrote:
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
expose 2D and 3D hardware acceleration
On Fri, 2004-06-04 at 04:16 +0200, Roland Scheidegger wrote:
Ian Romanick wrote:
Manuel Bilderbeek wrote:
Option GARTSize 64M
This doesn't work for me, the driver ignores all values supplied to that
parameter (dri tree). It accepts though values supplied to the old,
deprecated (?)
On Fri, 2004-06-04 at 16:48 +0200, Roland Scheidegger wrote:
Michel Dnzer wrote:
Couldn't it just use the largest GART size possible (set by the
bios), or would this have some negative consequences?
It could waste a lot of RAM.
But is this a problem? It surely eats away some of the
On Fri, 2004-06-04 at 17:48 +0200, Colin Leroy wrote:
just a lousy bugreport... I noticed that agpgart doesn't work anymore on
2.6.7-rc2. Xorg reports that AGP isn't supported, and dmesg doesn't show
the
agpgart: Putting AGP V2 device at :00:0b.0 into 4x mode
agpgart: Putting AGP V2
On Fri, 2004-05-28 at 23:18 -0500, Adam Jackson wrote:
On Friday 28 May 2004 19:49, Michel Dnzer wrote:
On Thu, 2004-05-27 at 11:08 -0700, Mike Mestnik wrote:
I try to keep each paragraph on topic, however this thread all started
with MergedFB. So I see where you could have gotten
On Fri, 2004-05-28 at 19:22 +0200, Roland Scheidegger wrote:
So, when I updated radeon_maos_arrays.c and compiled that (btw really
brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in
radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that
codepath was only enabled
On Thu, 2004-05-27 at 11:08 -0700, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
The data was shifted to the right, making it offcenter. I will need
to
find a way of undoing/compinsating-for this inorder to make
On Thu, 2004-05-27 at 11:27, Tomas Carnecky wrote:
Each slash in 'Mesa/DRI/DRM' stands for an interface, which is more or
less predefined (for example drm_*.h in drivers/char/drm).
No, it's not. Ian pointed that out, so why bring it up again?
--
Earthling Michel Dnzer | Debian
On Thu, 2004-05-27 at 12:04, Tomas Carnecky wrote:
I just don't think there should be one interface for all devices, as it
is now with DRM.
No, there isn't. There just happen to be some things common to all
drivers.
The userspace dri driver is the only user of these kernel drivers.
No,
On Tue, 2004-05-25 at 21:55, Nicolai Haehnle wrote:
As you may be aware, I was trying to get R300 support into a state where it
is possible to start OpenGL applications, let them hang the CP and *not*
bring down the entire machine.
Looks like I was successful :)
Nice!
The attached
On Thu, 2004-05-27 at 14:14, Tomas Carnecky wrote:
Michel Dnzer wrote:
The userspace dri driver is the only user of these kernel drivers.
No, there's also the DDX drivers, XvMC, ... and there could be more in
the future.
So you tell me that there are at least three
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard for me to recognize anything; can you describe your
observations?
I still have to find where rmesa-state.color.drawOffset comes from and
what effect the
On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard for me to recognize anything; can you describe your
On Sun, 2004-05-23 at 22:52, Dieter Ntzel wrote:
Program received signal SIGSEGV, Segmentation fault.
0x40670b99 in update_light (ctx=0x805e208) at r200_state.c:1143
1143 for (p = 0 ; p MAX_LIGHTS; p++) {
That doesn't make much sense, I don't see a pointer being dereferenced
here.
On Mon, 2004-05-24 at 03:25, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
I mean what about in places where this should have allready been done,
deep inside the driver. Do we
On Sun, 2004-05-23 at 11:32, Mike Mestnik wrote:
I think I finaly get it. When we have a window grater then 2048, we need
to run a GL command move the cliprect and run it again? The only way to
find out where we need is to SW render the cmd. Won't this cut our
framerate in half? Plus
On Sun, 2004-05-23 at 12:05, Nicolai Haehnle wrote:
This sounds like an idea for you to play with, but I'm afraid it won't
be useful very often in my experience:
* getting rid of the offending client doesn't help with a wedged
chip (some way to recover from that would be
On Sat, 2004-05-22 at 14:04, Nicolai Haehnle wrote:
It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
whether the caller actually holds the global lock. There is no
LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has
no check in it either.
Did
On Fri, 2004-05-21 at 00:49, Louis Garcia wrote:
Playing AA2 on my FC2 box with a radeon 7500 I noticed that the skin
color on people is way to light. Everything else looks normal. Anyone
have suggestions?
--Thanks
X.org-X11-6.7.0
This could be the attenuation bug which has been fixed
On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
Right now we can
On Wed, 2004-05-12 at 05:30, Jon Smirl wrote:
If everyone will please read Benh's original post describing this... Ben and I
had been emailing on this topic before he wrote this.
--- Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
I agree with the idea of moving the EDID decoding mode
On Tue, 2004-05-11 at 20:09, sottek wrote:
Can we wrap this up the discussion and try to get to a consensus on
design requirements? I think most of the opinions are starting to
solidify enough to start hashing out the requirements and actual
design.
I agree, and I like your initial list of
501 - 600 of 1646 matches
Mail list logo
