#Setting_display_resolution_and_bit_depth
Signed-off-by: Chris Ruffin
Reviewed-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_hw.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index 4603897..a39b034 100644
--- a/drivers/gpu/drm/bochs
On Mon, 05 Dec 2011 14:23:55 -0800, Eric Anholt wrote:
> On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris
> Wilson) wrote:
> > configure.ac |2 +-
> > intel/intel_bufmgr_gem.c | 27 +--
> > 2 file
On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> We've already seen that apps want to monitor the display config, and
> some (like upowerd) poll for changes since we don't provide a
> notification for general mode config changes, just hotplug events. So
> add a new drm event, with CHANGE=1 set in the
In order to satisfy a dependency upon a new kernel parameter for mesa,
it is time for a new release of libdrm. The usual bug fixes are a nice
bonus.
-Chris
Ben Skeggs (3):
nouveau: nvc0 drm has no concept of "notifier block"
nouveau: split pushbuf macros specific to nv04-nv5
On Thu, 06 Jan 2011 12:11:38 +0100, "David Müller (ELSOFT AG)"
wrote:
> The patch below adds an additional check to make sure that there is
> really an analog device attached (similar to the "Mac mini hack" in
> intel_sdvo.c)
Nice patch, thanks. I've appli
On Fri, 02 Jul 2010 11:54:44 -0400, Keith Packard wrote:
> On Fri, 02 Jul 2010 09:24:07 +0100, Chris Wilson
> wrote:
>
> > This looks like the responsibility of miCloseScreen(). Are we failing to
> > chain up properly?
>
> I don't think miCloseScreen (or fbCl
-> PictureCloseScreen -> fbCloseScreen
and fbCloseScreen supersedes miCloseScreen. So should it not be
fbCloseScreen that calls miCloseScreen, since fb has taken over the
management of the mi interface?
--
Chris Wilson, Intel Open Source Technology Centre
--
rsor image interleaved with the new cursor
> image on a row-by-row basis. Some kind of cache flush issue?
Exactly; a missing move-to-GTT-domain causing the cursor data to remain in
the CPU cache.
https://bugs.freedesktop.org/show_bug.cgi?id=28335
--
Chris Wilso
n off what may be a useful aid in desktop systems.
Also is TRACER the right name, that would seem to confuse the option with
a standalone tracer as opposed to simply enabling tracepoints.
-ickle
--
Chris Wilson, Intel Open Source Technology C
e 2ddd476af89a60fa ]---
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_fops.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 08d14df..4804872 100644
--- a/drivers/gpu/drm/drm_fo
bug #15248
Signed-off-by: Jesse Barnes
Cc: sta...@kernel.org
Signed-off-by: Eric Anholt
The Sony has a GMA 900, so does indeed need the quirk.
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
--
> Intel had it installed.
My bad, change it to noinst_HEADERS please.
--
Chris Wilson, Intel Open Source Technology Centre
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling,
From: Chris Nicholson
This is a patch to the nouveau_bios.c file that fixes up a
buffer overflow
Signed-off-by: Chris Nicholson
---
drivers/gpu/drm/nouveau/nouveau_bios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b
er 1073741824 (gen4 WM state): Bad file descriptor .\n",
> > 117) = 117
> > 1265267921.569039 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
This SEGV is just lazy error handling in the userspace driver; the
impossible just happened.
-ickle
--
Chris Wilson, Intel Open Source Tec
> [ 8505.847430] [drm:i915_gem_execbuffer] *ERROR*
> i915_gem_do_execbuffer returns -512
Apologies, this is not an error. It is an interrupted system call with an
overzealous DRM_ERROR() -- we will hopefully remove this printk promptly.
-ickle
--
Chris Wilson, Intel Open S
Hi,
I tripped over this KMS(?) bug this morning. I have a Radeon 9550, and the
userspace environment is Fedora 12. The kernel is vanilla 2.6.31.6.
Cheers,
Chris
BUG: unable to handle kernel NULL pointer dereference at 0028
IP: [] ttm_bo_wait+0x45/0x145 [ttm]
*pde =
Oops: [#1
1.4, so
understandably tries to dereference a NULL function pointer when calling
glGenBuffers. However if the application truly wishes to be cross-device,
it can check for ARB_vertex_buffer_object and use the glGenBuffersARB
[and friends] extension points instead.
Hope this
ght the only reason why pin() took an alignment parameter was so
that we could specify a minimum alignment of 64k for untiled scan out
buffers. Are we confident that this is not the case?
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
-
Implement support for purgeable objects by using the GEM madvise ioctl.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 134 -
src/mesa/drivers/dri/intel/intel_extensions.c |2 +
2 files changed, 135 insertions(+), 1 deletions
Signed-off-by: Chris Wilson
---
src/mesa/glapi/APPLE_object_purgeable.xml | 37 +
src/mesa/glapi/Makefile |1 +
src/mesa/glapi/gl_API.xml |1 +
3 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 src/mesa
Signed-off-by: Chris Wilson
---
src/mesa/main/api_exec.c |6 +
src/mesa/main/bufferobj.c | 350
src/mesa/main/bufferobj.h | 11 ++
src/mesa/main/dd.h | 15 ++
src/mesa/main/dlist.c |6 +
src/mesa/main/extensions.c |4
Large correction after Ian pointed out the fundamental flaw that the
various objects are separate structures and so require independent
interfaces.
Please review.
-ickle
--
Let Crystal Reports handle the reporting - Free
Signed-off-by: Chris Wilson
---
src/mesa/glapi/APPLE_object_purgeable.xml | 37 +
src/mesa/glapi/Makefile |1 +
src/mesa/glapi/gl_API.xml |1 +
3 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 src/mesa
Thank you Ian and Brian for your review, hopefully I've interpreted your
comments correctly and updated the patches appropriately.
-ickle
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
tri
Signed-off-by: Chris Wilson
---
src/mesa/main/api_exec.c |6 ++
src/mesa/main/bufferobj.c | 161
src/mesa/main/bufferobj.h | 11 +++
src/mesa/main/dd.h | 10 +++
src/mesa/main/extensions.c |4 +
src/mesa/main/mfeatures.h
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 43 +
src/mesa/drivers/dri/intel/intel_extensions.c |2 +
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src
Excerpts from Ian Romanick's message of Wed Nov 11 20:18:58 + 2009:
> Chris Wilson wrote:
> > +#if FEATURE_APPLE_object_purgeable
> > +static GLenum
> > +intel_bufferobj_purgeable(GLcontext * ctx,
> > + struct gl_buffer_object *obj,
ing 3 commits (XML, regeneration, real code) is
> probably even better.
Yes, this makes a lot of sense when trying to review these paths.
> Substantive comments are below.
>
> > Signed-off-by: Chris Wilson
> > ---
> > src/mesa/glapi/APPLE_object_purgea
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 43 +
src/mesa/drivers/dri/intel/intel_context.c|1 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src
atively simple, use the atomic variants of kmap() that
avoid the potential sleep.
Signed-off-by: Chris Wilson
Cc: Miles Lane
---
drivers/gpu/drm/i915/i915_debugfs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/driver
connectors are brought online.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_crtc_helper.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fe4e1d..54e2706 100644
owing patch prevents the glitch for me:
>From aa017e6056cf2faf6be7eeaa71d2fded4a9f6295 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Tue, 30 Jun 2009 18:21:54 +0100
Subject: [PATCH 1/3] drm: delay unpinning the current fb til after the flip is
complete
---
drivers/gpu/drm/drm_crtc.
Revised patch, unmap_mapping_range() on unbind and clear register.
>From 8f13b6389ee0c8a39a2073279928a3a228bd27dc Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Mon, 29 Jun 2009 08:45:31 +0100
Subject: [PATCH] drm/i915: Remove mappings on clearing fence register
As the fence register is
nge on clear - which could also cause
tiling errors if textures were being written via a GTT mmap.
So please can you try this patch:
>From 20b7c9322914213bb589035afbbc03faf1ae3bf0 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Mon, 29 Jun 2009 08:45:31 +0100
Subject: [PATCH] drm/i915: Remo
On Sun, 2009-06-21 at 17:47 +0300, Maxim Levitsky wrote:
> > 52dc7d32b88156248167864f77a9026abe27b432 is first bad commit
> > commit 52dc7d32b88156248167864f77a9026abe27b432
> > Author: Chris Wilson
> > Date: Sat Jun 6 09:46:01 2009 +0100
The error here seems to be my p
Dave,
this is an old patch that seems to have slip through the net, without
it my i915 runs out of GTT space within seconds during firefox replays.
>From e2cf2574d43f12934a20d2672d47fec082db7c5a Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Fri, 22 May 2009 13:52:03 +0100
Subject: [PA
If the block needs an alignment but otherwise fits exactly into the tail,
then the split-off block from the start would remain marked as non-free.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git
Commit 201361a5 introduces a leak when unwinding on error. Reorder
unwind, and eliminate leak.
Cc: Eric Anholt
Cc: Keith Packard
Cc: Jesse Barnes
Signed-off-by: Chris Wright
---
drivers/gpu/drm/i915/i915_dma.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a
7568b1eab18a33dd9edc3579ce5 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Wed, 11 Feb 2009 10:45:16 +
Subject: [PATCH] drm/i915: Clear fence register on tiling stride change.
The fence register value also depends upon the stride of the object, so
we
need to clear the fence if that is chan
On Thu, 2009-02-26 at 14:35 -0800, Jesse Barnes wrote:
> On Thursday, February 26, 2009 1:56:52 pm Chris Wilson wrote:
> > On Thu, 2009-02-26 at 13:28 -0800, Jesse Barnes wrote:
> > > Add a new page flip ioctl to the i915 driver. The new ioctl takes the
> > > new drm_i9
I've hit the occasional oops inside i915_wait_ring() with an indication of
a NULL derefence of dev->primary->master. Adding a NULL check is
consistent with the other potential users of dev->primary->master.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c |
On Thu, 2009-02-26 at 14:35 -0800, Jesse Barnes wrote:
> > > + ret = i915_gem_object_pin(obj, 0);
> > > + if (ret) {
> > > + DRM_ERROR("failed to pin object for flip\n");
> > > + ret = -EBUSY;
> >
> > What's the rationale for changing the reported err
On Thu, 2009-02-26 at 13:28 -0800, Jesse Barnes wrote:
> Add a new page flip ioctl to the i915 driver. The new ioctl takes the new
> drm_i915_gem_page_flip arg, which contains a buffer object target for the
> flip, an offset into that buffer, and other buffer parameters to be used for
> the flip.
Hi,
Attached patch fixes a simple typo introduced in 4d5341340fb that was
causing libdrm_nouveau not be built, regardless of configure flags.
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Regards,
--
,''`.
: :' : Chris Lamb
The object is dereferenced before the NULL check. Oops.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20235
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
Hello all,
I'm seeing a bizarre problem whilst running wayland/cairo-drm/i915 under
KMS. Occasionally after pressing a key (which is handled by wayland
through the input layer) the dark regions (I'm estimating where the
value is less than ~4) become garbage. I've managed to capture a
screenshot be
On Fri, 2009-02-20 at 13:46 +0800, Zou, Nanhai wrote:
> >+struct drm_i915_gem_page_flip {
> >+/** Handle of new front buffer */
>
> Should this be handle of new front buffer or handle of the execbuf?
I can't see how this can be an execbuf here. Do you mind elaborating?
Anyway this remin
On Thu, 2009-02-19 at 16:43 -0800, Jesse Barnes wrote:
> On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> > With a few additional suggestions by Jesse, I've managed to get
> > tear-free compositing working on i915. Here's the diff on top of the
> > origin
With a few additional suggestions by Jesse, I've managed to get
tear-free compositing working on i915. Here's the diff on top of the
original patch (though obviously this is just a suggestion, still need
to prevent multiple pending flips to the same plane and ensure that the
old buffer is eventuall
On Mon, 2009-02-16 at 10:55 -0800, Jesse Barnes wrote:
> On Sunday, February 15, 2009 4:02 pm Chris Wilson wrote:
> > On my i915, the flip never occurs and we wait forever on the the vblank.
> > So I presume the command we sent the chip is invalid, or we miss the
> > irq? (
On Thu, 2009-02-12 at 16:52 -0800, Jesse Barnes wrote:
> This adds a new ioctl for queueing a page flip with GEM objects. There's a
> completion per private object, that we use at execbuf time to wait for any
> pending flips; it's cleared at vblank interrupt time when the flip occurs.
> The kernel
On Thu, 2009-02-12 at 14:37 -0500, Kristian Høgsberg wrote:
> Avoids leaking fbs and associated buffers on release.
>
> Signed-off-by: Kristian Høgsberg
Tested-by: Chris Wilson
--
Open Source Business Confere
I tried it, it's not too happy. My only concern is that this now relies
on userspace to correctly call SW_FINISH (and not unmap after mmapping
the GTT_MMAP) or otherwise the object is leaked? Patch comments inline.
On Fri, 2009-02-06 at 14:24 -0800, Jesse Barnes wrote:
> This one should cover the
On Tue, 2009-02-03 at 22:33 -0800, Eric Anholt wrote:
> The basic problem was
> mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap())
> struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
>
> We have plenty of places where we want to hold device state the same
> (struct_mutex) w
--- Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Arg, eventually I'll send this mail correctly (last one was rejected
> since my @intel.com address isn't a subscriber).
>
> How does this one look?
Well, it compiles and doesn&#
27;t see NULL as an error at all (at least not until dereferencing it.)
Look at include/linux/err.h to see how this works.
As an aside, please accept my apology for the poor formatting of the
patch.
--
Chris Lesiak
[EMAIL PROTECTED]
---
ULL;
+ if (IS_ERR(class_dev))
+ return class_dev;
class_set_devdata(class_dev, head);
--
Chris Lesiak
[EMAIL PROTECTED]
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integ
n 1.20.0 20050911 on minor 0:
agpgart: Found an AGP 3.0 compliant device at :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 4x mode
agpgart: Putting AGP V3 device at :01:00.0 into
] *ERROR* radeon_emit_packets failed
I have reverted to the DRI modules that are built as part of 2.6.14.5 instead,
as these work OK
with the same Xorg release.
My kernel is 2.6.14.5-SMP, built with gcc-3.4.4. (Dual P4 Xeon with HT enabled.)
Cheers,
Chris
oW with the r300 driver
yields this complaint:
Your 3D accelerator card is not supported by World of Warcraft.
Please install a 3D accelerator card with dual-TMU support.
Anyone know if this is a known limitations or whatnot?
For kicks, in case it's interesting to anyone, I put my Xorg.log up as
ed 75 e9 5b 89 f0 5e 5f
Jun 25 22:15:44 hypercube kernel: <6>SysRq : Emergency Remount R/O
Cheers,
Chris
___
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photo
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Could you add this line to the
> end of mga_driver_preinit *and* to the beginning of mga_dma_init:
>
> DRM_ERROR("dev = %p, dev_private = %p\n", dev, dev->dev_private);
>
> That should shed some light on
things.
OK, I should have access to that box again some time on Wednesday.
Cheers,
Chris
___
How much free photo storage do you get? Store your holiday
snaps for FREE with Yah
May 22 17:26:33 hypercube kernel: Unable to handle kernel NULL pointer
dereference at virtual
address 0080
May 22 17:26:33 hypercube kernel: printing eip:
May 22 17:26:33 hypercube kernel: dab62bc5
May 22 17:26:33 hypercube kernel: *pde = 0fafd067
May 22 17:26:33 hypercube kernel: *pte =
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> Does commenting out Option "AGPMode" make a
difference?
Alas, no. But it got my hopes up for a minute
longer... Here is the log file from the session.
Safely back at 6.8.1 for
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> Try removing the RADEONSetFBLocation() call in
> RADEONAdjustFrame().
By the power of my serial console, here is what gdb
says about my crazy celestia-1.3.2 process:
0xe410 in __kernel_vsyscall ()
(gdb) where
#0 0xe410 in __kernel_vsyscall
ll. I am sticking with 6.8.1 for now.
Cheers,
Chris
___
ALL-NEW Yahoo! Messenger - all new features - even more fun!
http://uk.messenger.yahoo.com
-
w how it checks out.
Cheers,
Chris
___
ALL-NEW Yahoo! Messenger - all new features - even more fun!
http://uk.messenger.yahoo.com
---
SF email is s
ights
parm: cards_limit:Maximum number of graphics
cards
parm: drm_debug:Enable debug output
vermagic: 2.6.10 SMP PENTIUM4 REGPARM 4KSTACKS
gcc-3.4
depends:agpgart
[EMAIL PROTECTED] chris]$ /sbin/modinfo radeon
author: Gareth Hughes, Keith Whitwell, others.
description:ATI Rade
ds
parm: debug:Enable debug output
vermagic: 2.6.10 SMP PENTIUM4 REGPARM 4KSTACKS
gcc-3.4
depends:i2c-algo-bit
I haven't tried the in-tree kernel module.
Cheers,
Chris
___
ALL-NE
d although I say "locked up the X server", I was
still able to move the mouse cursor around. However,
the cursor graphic stopped changing, and the screen
was no longer being updated.)
Cheers,
Chris
Linux 2.6.10-SMP (2 Xeon
of the 'migration' threads in
2.6.9 was consuming a lot of CPU time with the in-tree
radeon module.)
Is the CVS linux-2.6 directory considered 'dead',
then? It seems stable enough. How stable is code in
linux-core?
Cheers,
Chris
_
Hi,
I just tried booting the new 2.6.10 kernel with the
radeon DRM module from CVS (at dri.freedesktop.org),
and the IRQ was left unrouted at IRQ 11:
[drm] Initialized radeon 1.13.0 20041207 on minor 0:
ATI Technologies Inc RV280 [Radeon 9200]
ACPI: PCI interrupt :01:00.0[A] -> GSI 16 (level,
I am interested in helping in getting DRI working
with different ATI chipsets. I have at my disposal the
following.
Radeon 9000 PCI
Radeon 9200se AGP
Radeon 9600XT
If someone can inform me as to how I would go about
reverse engineering the windows drivers, I could write small programs to
tionality they provide. Or maybe not. What's the favored path?
Thanks,
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - C
* Andrea Arcangeli ([EMAIL PROTECTED]) wrote:
> On Fri, Apr 16, 2004 at 11:54:06AM -0700, Chris Wright wrote:
> > + if (mc.idx >= dma->buf_count)
> > + return -EINVAL;
> > +
> > i810_dma_dispatch_mc(dev, dma->buflist[mc.idx], mc.used,
> >
;counts[_DRM_STAT_SECONDARY]);
Looks like a possible bug. Index shouldn't go off end of buflist.
Perhaps verifying it's below buf_count would do it. Patch below.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
= drivers/char/drm/i810_
Okay, I tried both solutions (decreasing bit-depth and allocating more
memory) and they both solved all the problems I was having. I'm right
now running at 32bpp, and it's working great (as did 24). Thanks!
- Chris K
---
SF.Net is
Okay, I tried both solutions (decreasing bit-depth and allocating more
memory) and they both solved all the problems I was having. I'm right
now running at 32bpp, and it's working great (as did 24). Thanks!
- Chris K
---
SF.Net is
>
> Yes, lefover is always 0 in this case so we could simplify that. Care
> to send a patch? Otherwise, I'll get to it later.
>
There is quite a few cases that could be more simplified, I just used the
bgr888->rgba conversion as an example. I can go through and work it out
for each conversion
*helps if I send to the list*
> Maybe I don't understand what you're saying.
ok atm, the code for texsubimage2d_bgr888_to_rgba looks partially like
this
#define DST_TEXELS_PER_DWORD 1
#define CONVERT_TEXEL( dst, src ) \
dst = PACK_COLOR__LE( src[0], src[1], src[2], 0xff )
#define C
> For texture RGB888 is that 24bit packed or with 8bits of empty ?
Looking at the texsubimage source for bgr888->rgba conversion, it
appears to be 24bits packed, but I could be wrong, all the macros make it a
little difficult to follow.
ADMIN: please ignore pending email
> I'm wondering though why the heck quakeworld actually uses so much
> texsubimage2d calls. Typically, games specify textures at level load
> time and leave them completely alone after that - at least those games I
> profiled with oprofile never showed texsubimag
> What do you mean by "hardware TexSubImage"?
>
Maybe I'm reading it wrong but looking at these texbubimage functions, they
all copy out a the part of the texture to use, what I'm wondering is if
there is a way to tell the card to do that.
Also, atm Mesa falls back to software for vertex arrays, i
ered memory is being overwritten). Is
this 'normal' (being in development), or is something wrong with my setup?
Thanks!
- Chris K
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux
although I can't find it in mesa, does the r200
drm/dri have a way or method of doing hardware TexSubImage? and if not, does the
specs have infomation on doing hardware TexSubImage.
a particular conversion.
This would also make it much easier later on to add further conversion types
and methods.
Chris Ison
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux
call or just called alot (as oprofile doesn't
give you that information)
Thanks in advance
Chris Ison
> oprofile perhaps might help.
The problem is oprofile is it works only on sample count which does not
reflect how many times a function was called, nor does it reflect time per
function call. It only shows that then oprofile checked, it was in that
function.
Here is the initial oprofile done on
ok, let me get this in perspective
R9200R8500
DRI14.62103716.860273
fglrx39.46159444.228085
I have been trying to hunt down the slowdown in DRI, I even if (0)'s all
occurances of sched_yield () which is slower in 2.6 than 2.4 due to 2.6
doing it properly.
Acco
> You know how to verify that...
I've actually forgotten how, I think its an enviroment setting, but none of
the settings I saw when I grep'd for getenv triggered my memory.
> I'm sure you've tried page flipping and ruled out things like usleeps in
> the client side drivers?
enableing page flipp
> You know how to verify that...
I've actually forgotten how, I think its an enviroment setting, but none of
the settings I saw when I grep's getenv triggered my memory.
> I'm sure you've tried page flipping and ruled out things like usleeps in
> the client side drivers?
usleeps in dri? there wo
ADMIN: ignore my foobar'd post
--
Note also from a Quakeforge developer,
WildCode: maybe you should mention my r100 gets ~44 fps :) (hang on
and I'll get a fresh run)
make that 42, with -nosound (39 with sound)
actually, I'm using a rather old dri
So the gigabyte binary windows drivers for this Radeon 9200SE (AGP) card are
faulty, and it really should perform the same as the PCI Radeon 9000?
> I would expect them to perform about the same, with the
> AGP bus providing a slight performance boost. To be honest, I'm not
> sure why your window
nfig
http://wildmidi.sf.net/XFree86.0.log
http://wildmidi.sf.net/glxinfo.out
http://wildmidi.sf.net/misc.out
(this is the full output of lspci -vvv)
Hope you can help
Chris Ison
f I'm
wrong.
Chris Ison
> Which hardware/driver are you using under Linux?
I use a radeon 9000 PCI with r200 DRI cvs (2 weeks ago)
Others who have also tested and saw the same result were using radeon 8500
and radeon 9200, both AGP.
However, as stated in previous email, in windows using catalyst the
multitexture is fas
multitexture is faster than multipass as seen
with nVidia in linux, and nVidia and ATI in windows.
Thanks in advance
Chris Ison
thanks, turned out to be a permissions thing, dunno how they changed.
Also note, its a PCI Radeon 9000, this AMD athlon 2000+ only seems to be
able to push about 450fps out of glxgears with direct rendering, can't help
wondering if something is setup wrong, but as discussed here several times,
th
I've compiled compiled and installed Xfree86, DRI from cvs, with mesa cvs,
last night, thismorning I confirmed it all worked by loading the radeon drm
and running glxinfo showing direct rendering enabled
however, when I ran glxgears, I get a libGL error saying it couldn't load
the drm and it was r
1 - 100 of 193 matches
Mail list logo
