Re: Please revert nouveau.
On Sun, 2011-01-16 at 12:10 -0800, Linus Torvalds wrote: On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel anca.eman...@gmail.com wrote: In 2.6.37-git5 with the revert, the boot screen is changing the resolution. With this version, it don't. So, can you make a nice report of that - along with 'dmesg' for _both_ cases - to the right people? In this case, that would be at a minimum James, Dave and Ben (added here to the list of people), along with the dri-devel mailing list. I've tested a bit here, current git with the revert does appear to work fine for me. Ben. ( For people newly added to the cc: the revert in question is the revert of dfe63bb0ad9. It was committed mainline in commit 3632ef89091, but apparently there's still something missing because that isn't sufficient any more ) Linus -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Please revert nouveau.
On Sun, 2011-01-16 at 15:48 -0800, Linus Torvalds wrote: On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs bske...@redhat.com wrote: I've tested a bit here, current git with the revert does appear to work fine for me. So Anca has a 8800GT - is that what you're testing? I don't have an 8800 in the office, testing on a Quadro FX 570M, which is identical from an acceleration standpoint. Also confirmed the revert fixes the same issue on GTX465, and NV44/NV4B (GeForce 6/7 boards). Also, there may be things like FB config issues and/or kernel command line arguments. For example, on the Intel side, we had people who had non-working Intel modesetting because they had VESAFB and the legacy INTELFB enabled. Did some ordering change so that perhaps having VESA enabled took priority and then breaks the accelerated case or something? Not that I can think of, I'll wait until I see Anca's dmesg from after the revert. Ben. Linus -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] nouveau: off by one in nv50_gpio_location()
On Thu, 2010-04-22 at 11:40 +0200, Dan Carpenter wrote:
If gpio-line is 32 then nv50_gpio_reg[gpio-line 3] reads past the
end of the array.
Thanks, picked up in the nouveau tree.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/gpu/drm/nouveau/nv50_gpio.c
b/drivers/gpu/drm/nouveau/nv50_gpio.c
index c61782b..bb47ad7 100644
--- a/drivers/gpu/drm/nouveau/nv50_gpio.c
+++ b/drivers/gpu/drm/nouveau/nv50_gpio.c
@@ -31,7 +31,7 @@ nv50_gpio_location(struct dcb_gpio_entry *gpio, uint32_t
*reg, uint32_t *shift)
{
const uint32_t nv50_gpio_reg[4] = { 0xe104, 0xe108, 0xe280, 0xe284 };
- if (gpio-line 32)
+ if (gpio-line = 32)
return -EINVAL;
*reg = nv50_gpio_reg[gpio-line 3];
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] nouveau fixes
Hopefully doing this right, we'll see! Various fixes across the board + support for the NVA3 chipset. The following changes since commit 95beb690170e6ce918fe53c73a0fcc7cf64d704a: Alex Deucher (1): drm/radeon/kms/atom: fix gpio i2c table overrun (v2) are available in the git repository at: git://anongit.freedesktop.org/nouveau/linux-2.6 for-airlied Ben Skeggs (16): drm/nv50: fix fbcon when framebuffer above 4GiB mark drm/nv50: add more 0x100c80 flushy magic drm/nouveau: remove some unused members from drm_nouveau_private drm/nouveau: detect vram amount once, and save the value drm/nv40: rework lvds table parsing drm/nv40: add LVDS table quirk for Dell Latitude D620 drm/nv50: fix instmem init on IGPs if stolen mem crosses 4GiB mark drm/nouveau: fixup the init failure paths some more drm/nv50: cleanup properly if PDISPLAY init fails drm/nv50: preserve an unknown SOR_MODECTRL value for DP encoders drm/nv50: punt hotplug irq handling out to workqueue drm/nv50: another dodgy DP hack drm/nouveau: store raw gpio table entry in bios gpio structs drm/nv50: parse/use some more de-magiced parts of gpio table entries drm/nv50: implement gpio set/get routines drm/nouveau: bail out of auxch transaction if we repeatedly recieve defers Francisco Jerez (2): drm/nouveau: Make use of TTM busy_placements. drm/nv40: Init some tiling-related PGRAPH state. Marcin Kościelnicki (3): drm/nv50: Fix NEWCTX_DONE flag number drm/nv50: Allow using the NVA3 new compute class. drm/nv50: Add NVA3 support in ctxprog/ctxvals generator. drivers/gpu/drm/nouveau/Makefile |2 +- drivers/gpu/drm/nouveau/nouveau_bios.c| 127 +--- drivers/gpu/drm/nouveau/nouveau_bios.h|4 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 67 --- drivers/gpu/drm/nouveau/nouveau_channel.c |2 - drivers/gpu/drm/nouveau/nouveau_debugfs.c |5 +- drivers/gpu/drm/nouveau/nouveau_dp.c |8 ++- drivers/gpu/drm/nouveau/nouveau_drv.h | 40 +- drivers/gpu/drm/nouveau/nouveau_encoder.h |1 + drivers/gpu/drm/nouveau/nouveau_gem.c | 55 ++--- drivers/gpu/drm/nouveau/nouveau_irq.c |1 + drivers/gpu/drm/nouveau/nouveau_mem.c | 124 +--- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 18 drivers/gpu/drm/nouveau/nouveau_state.c | 14 +++- drivers/gpu/drm/nouveau/nv40_fifo.c |2 +- drivers/gpu/drm/nouveau/nv40_graph.c | 21 + drivers/gpu/drm/nouveau/nv50_display.c| 22 +++-- drivers/gpu/drm/nouveau/nv50_display.h|1 + drivers/gpu/drm/nouveau/nv50_fbcon.c | 13 ++-- drivers/gpu/drm/nouveau/nv50_gpio.c | 76 + drivers/gpu/drm/nouveau/nv50_graph.c |7 +- drivers/gpu/drm/nouveau/nv50_grctx.c | 19 - drivers/gpu/drm/nouveau/nv50_instmem.c| 16 ++--- drivers/gpu/drm/nouveau/nv50_sor.c| 25 ++- 24 files changed, 429 insertions(+), 241 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nv50_gpio.c -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 16:08 -0800, Linus Torvalds wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: Speaking as distro maintainer here, No because we've got versioned interfaces and we are happy to support them yes it would be nice sometimes to dream about this, but its a major explosion in the testing matrix. You have to realise the more codepaths a distro ships, the more codepath it has to keep track off for security issues, for bug fixes, etc. I think you're missing the whole point here. There's no new and complex testing matrix. You only ever test the newest version, so there's no additional testing. Here's the inductive proof: - if the version number doesn't change, you aren't doing anything that is at all different from what you already do. - if the version number _does_ change, it does so only because you updated both the kernel component and the libdrm component together, and you test them together - exactly like you already do. So there is absolutely no difference for you. In either case, you only ever test paired up versions. If you make a new version, it will never _ever_ interact with old versions. There's no new complex testing needed. The only thing it allows is for you to have multiple kernels installed simultaneously - and be able to _use_ them all. Which is something you already do. And which the current model doesn't allow for. You may have three different kernels installed, but if libdrm got updated with a version change, only one of those kernels will actually _work_. When to we decide to stop shipping nouveau_drv-0.0.13? when do we find out it has a security issue? Irrelevant and total red herring. You never care about older versions, since if people have updated, they are running the newer version. So the older versions are there purely so that you _can_ have multiple different kernels, and so that your _developers_ can compile new kernels for older distributions. They aren't relevant for the case you point to: if somebody is just doing yum update, they'll get - and use - the newer version anyway. Here's the thing, distros are trying to ship an OS with a consistent set of packages, not a pick-n-mix. But here's the thing: if you expect people to do development, they _need_ to be able to mix things. A kernel developer needs to be able to update their kernel. And a kernel _tester_ needs to be able to test that kernel. Here's the thing. *You* pushed for nouveau to go into staging before any of the developers were ready for it. Two of the big reasons (from my POV) for not requesting inclusion were the context programs (which have since been dealt with) and that yes, we have no intention of keeping crusty APIs around when they aren't what we require. The idea of staging was to allow for exactly the second problem, so why are you surprised? The fact Fedora ships nouveau is irrelevant, we also expect that for the most part people will be using our packages, which deal with the ABI issues. Seriously: what do you expect me to do right now in my situation? I'm not going to release a kernel that I can't test. So if I can't get a libdrm that works in my F12 environment, I will _have_ to revert that patch that you asked me to merge. The F13 packages *will* work, so long as you're not bisecting back and forth. Really. Look at it from my standpoint. Look at it from _any_ kernel developer standpoint. It would be totally irresponsible of me to release 2.6.34 without even eating my own dog-food on my own main machine. Can't you see that this is obviously true? With the release of 2.6.34 it'll require people to update userspace *once*, if they're rolling their own kernels and not using distro provided packages they should be able to handle that much. I agree it's a pain to bisect through, really. But it's far far from the common use case. Ben. So right now, I'm running with that patch reverted on that machine. I haven't committed the revert, and quite frankly, I'd really prefer not to. But the only way that not revert case can really happen is if there is some other way for me to have a working machine again. Think about it. Tell me what the solution is. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself.
Re: [git pull] drm
On Mon, 2010-02-15 at 23:55 +0100, Christian Borntraeger wrote: Am Montag 15 Februar 2010 10:53:48 schrieb Christian Borntraeger: I think this regression is triggered by commit 39c9bfb453b748ce220ceefacbe2a5c19fabf67b Author: Ben Skeggs bske...@redhat.com Date: Tue Feb 9 10:22:29 2010 +1000 drm/nv50: prevent multiple init tables being parsed at the same time One possible solution is to replace the spinlock bios-lock with a mutex, but there are others ways of fixing this BUG. CCing Ben. Ah, it appears the vbios delay opcodes got changed to use sleeps rather than delays at some point without me noticing. Sent a patch to Dave changing the code to use a mutex instead for now. Thanks, Ben. [2.175437] BUG: scheduling while atomic: nouveau/0/753/0x0002 [2.175439] Modules linked in: [2.175442] Pid: 753, comm: nouveau/0 Not tainted 2.6.33-rc8-prerelease #27 [2.175443] Call Trace: [2.175451] [815dcdea] ? schedule+0x86a/0x880 [2.175454] [8120a420] ? vsnprintf+0xe0/0x9a0 [2.175456] [815dd18c] ? schedule_timeout+0x15c/0x250 [2.175460] [81068570] ? process_timeout+0x0/0x10 [2.175462] [81069068] ? msleep+0x18/0x30 [2.175466] [812d48d1] ? init_time+0x51/0x90 [2.175468] [812d3ffb] ? parse_init_table+0xcb/0x1a0 [2.175470] [812d424a] ? init_sub_direct+0x4a/0xd0 [2.175472] [812d3ffb] ? parse_init_table+0xcb/0x1a0 [2.175474] [812d496f] ? nouveau_bios_run_init_table+0x5f/0xa0 [2.175476] [812d4c0c] ? nouveau_bios_run_display_table+0x25c/0x500 [2.175480] [812fd220] ? nv50_display_irq_handler_bh+0x0/0x410 [2.175483] [812fd4cc] ? nv50_display_irq_handler_bh+0x2ac/0x410 [2.175485] [812fd220] ? nv50_display_irq_handler_bh+0x0/0x410 [2.175487] [8107047b] ? worker_thread+0x16b/0x250 [2.175490] [81074240] ? autoremove_wake_function+0x0/0x30 [2.175492] [81070310] ? worker_thread+0x0/0x250 [2.175494] [81070310] ? worker_thread+0x0/0x250 [2.175496] [81073dbe] ? kthread+0x8e/0xa0 [2.175499] [81027554] ? kernel_thread_helper+0x4/0x10
Re: Another TTM race bug.
On Wed, 2009-12-16 at 12:11 +0100, Thomas Hellstrom wrote: Jerome Glisse wrote: On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote: Hi guys, There is another TTM race bug that I'm going to fix but which doesn't yet affect any upstream code AFAICT. The effect is that it may cause a deadlock in extremely rare cases if there are two processes validating at the same time, and one process needs to evict a buffer on which ttm_bo_block_reservation has been called. I'll fix that up before we upstream any driver that allows simultaneous validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx probably will at some point. /Thomas GL app likely endup doing concurrent validation with the ddx on radeon. Jerome I thought you had a command submission mutex that blocked this possibility? If not, you'll need the execbuf utilities to avoid deadlocks resulting from multiple threads trying to reserve the same buffers but in reverse order. Nouveau actually has an implementation of what ttm_eu did (we used it before the initial patch to the kernel which didn't include it) in the driver. Now that ttm_eu exists again I should look at moving back to it. We also have a mutex blocking submission by multiple clients currently, I can't recall why I added it right now, but it's on my TODO list to remove at some point. Ben. /Thomas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Rework validation memory space allocation (V3)
On Tue, 2009-12-08 at 15:33 +0100, Jerome Glisse wrote:
This change allow driver to pass sorted memory placement,
from most prefered placement to least prefered placement.
In order to avoid long function prototype a structure is
used to gather memory placement informations such as range
restriction (if you need a buffer to be in given range).
Range restriction is determined by fpfn lpfn which are
the first page and last page number btw which allocation
can happen. If those fields are set to 0 ttm will assume
buffer can be put anywhere in the address space (thus it
avoids putting a burden on the driver to always properly
set those fields).
This patch also factor few functions like evicting first
entry of lru list or getting a memory space. This avoid
code duplication.
V2: Change API to use placement flags and array instead
of packing placement order into a quadword.
V3: Make sure we set the appropriate mem.placement flag
when validating or allocation memory space.
A way to pass fpfn/lpfn to ttm_buffer_object_{init,create}() would be
really useful too. Perhaps passing a struct ttm_placement rather than
flags to these functions?
Ben.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c| 463
+++
include/drm/ttm/ttm_bo_api.h| 42 +++-
include/drm/ttm/ttm_bo_driver.h | 20 +--
3 files changed, 256 insertions(+), 269 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 87c0625..9476bde 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -27,6 +27,14 @@
/*
* Authors: Thomas Hellstrom thellstrom-at-vmware-dot-com
*/
+/* Notes:
+ *
+ * We store bo pointer in drm_mm_node struct so we know which bo own a
+ * specific node. There is no protection on the pointer, thus to make
+ * sure things don't go berserk you have to access this pointer while
+ * holding the global lru lock and make sure anytime you free a node you
+ * reset the pointer to NULL.
+ */
#include ttm/ttm_module.h
#include ttm/ttm_bo_driver.h
@@ -247,7 +255,6 @@ EXPORT_SYMBOL(ttm_bo_unreserve);
/*
* Call bo-mutex locked.
*/
-
static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
{
struct ttm_bo_device *bdev = bo-bdev;
@@ -328,14 +335,8 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
}
if (bo-mem.mem_type == TTM_PL_SYSTEM) {
-
- struct ttm_mem_reg *old_mem = bo-mem;
- uint32_t save_flags = old_mem-placement;
-
- *old_mem = *mem;
+ bo-mem = *mem;
mem-mm_node = NULL;
- ttm_flag_masked(save_flags, mem-placement,
- TTM_PL_MASK_MEMTYPE);
goto moved;
}
@@ -418,6 +419,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo, bool remove_all)
kref_put(bo-list_kref, ttm_bo_ref_bug);
}
if (bo-mem.mm_node) {
+ bo-mem.mm_node-private = NULL;
drm_mm_put_block(bo-mem.mm_node);
bo-mem.mm_node = NULL;
}
@@ -554,17 +556,14 @@ void ttm_bo_unref(struct ttm_buffer_object **p_bo)
}
EXPORT_SYMBOL(ttm_bo_unref);
-static int ttm_bo_evict(struct ttm_buffer_object *bo, unsigned mem_type,
- bool interruptible, bool no_wait)
+static int ttm_bo_evict(struct ttm_buffer_object *bo, bool interruptible,
+ bool no_wait)
{
- int ret = 0;
struct ttm_bo_device *bdev = bo-bdev;
struct ttm_bo_global *glob = bo-glob;
struct ttm_mem_reg evict_mem;
- uint32_t proposed_placement;
-
- if (bo-mem.mem_type != mem_type)
- goto out;
+ struct ttm_placement placement;
+ int ret = 0;
spin_lock(bo-lock);
ret = ttm_bo_wait(bo, false, interruptible, no_wait);
@@ -584,14 +583,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
unsigned mem_type,
evict_mem = bo-mem;
evict_mem.mm_node = NULL;
- proposed_placement = bdev-driver-evict_flags(bo);
-
- ret = ttm_bo_mem_space(bo, proposed_placement,
-evict_mem, interruptible, no_wait);
- if (unlikely(ret != 0 ret != -ERESTART))
- ret = ttm_bo_mem_space(bo, TTM_PL_FLAG_SYSTEM,
-evict_mem, interruptible, no_wait);
-
+ bdev-driver-evict_flags(bo, placement);
+ ret = ttm_bo_mem_space(bo, placement, evict_mem, interruptible,
+ no_wait);
if (ret) {
if (ret != -ERESTART)
printk(KERN_ERR TTM_PFX
@@ -605,95 +599,117 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
unsigned
Re: [PATCH] drm: update crtc x/y when only fb changes
On Thu, 2009-09-17 at 08:24 +0200, Maarten Maathuis wrote:
On Thu, Sep 17, 2009 at 8:15 AM, skeg...@gmail.com wrote:
From: Ben Skeggs bske...@redhat.com
Fixes:
xrandr --output DVI-I-0 --right-of DVI-I-1
xrandr --output DVI-I-0 --left-of DVI-I-1
xrandr --output DVI-I-0 --right-of DVI-I-1
Signed-off-by: Ben Skeggs bske...@redhat.com
---
drivers/gpu/drm/drm_crtc_helper.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ff447f1..810e867 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -869,13 +869,21 @@ int drm_crtc_helper_set_config(struct drm_mode_set
*set)
}
drm_helper_disable_unused_functions(dev);
} else if (fb_changed) {
+ int saved_x = set-crtc-x, saved_y = set-crtc-y;
+
+ set-crtc-x = set-x;
+ set-crtc-y = set-y;
+
old_fb = set-crtc-fb;
if (set-crtc-fb != set-fb)
set-crtc-fb = set-fb;
ret = crtc_funcs-mode_set_base(set-crtc,
set-x, set-y, old_fb);
- if (ret != 0)
+ if (ret != 0) {
+ set-crtc-x = saved_x;
+ set-crtc-y = saved_y;
This should not be needed for drm-next and friends, the fail path will
restore everything. For older code this is needed. The relevant commit
is drm/crtc_helper: replace modeset fail path with something
simpler.
Good point, I missed this. Will fixup and resend before Dave gets to
pushing it into drm-next.
Ben.
goto fail;
+ }
}
kfree(save_connectors);
--
1.6.4.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: speed up EDID detection.
On Wed, 2009-05-06 at 03:12 +0100, Dave Airlie wrote: This just tries EDID detection, then falls back to the slow path code. I think this is should detect most monitors currently available. I need to rework the I2C stuff so that it doesn't require the bit-bang i2c algo; Display Port needs a custom i2c algo. As such, it seems like the slow i2c stuff should be pushed into it's own algo and used by whichever modules need it (does anything other than VGA actually need this?) Well if you just call the get_edid and ignore all the setscl crap that this code does, then you should be able to just implement a new i2c algo, and have it all just work. It's definitely possible, the nv50 kms driver used to implement its own i2c algo until recently. Ben. I've no idea what monitors this picks up on, radeon used to do it, and the kernel fb layer does it but I think got it from radeon originally. I suspect dropping it might not be a bad idea. Dave. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium HW winsys
Am Freitag, den 11.07.2008, 16:56 +0200 schrieb Jakob Bornecrantz: On Thu, Jul 10, 2008 at 6:22 PM, Younes Manton [EMAIL PROTECTED] wrote: I'm trying to get the HW winsys stuff set up for XvMC and have some questions. Is there any problem with dlopen()ing the DRI driver (in this case nouveau_dri.so) and instead of writing my own winsys? Stephane suggested I look into this, even though the winsys is supposed to be tied to the API. For Softpipe I looked at what Mesa's winsys was doing and implemented the stuff I needed and ignored any GL-specific things, but I realize now I may have been able to load egl_softpipe.so and reused their winsys. Is this acceptable for nouveau if I can live with some possibly minor GL dependencies?. I'm looking at dri_glx.c and glxext.c to see how this might be done. As things currently are you need to make sure that libGL.so linked to the application. I think it just enough to dlopen() it GLOBAL and then dlopen *_dri.so you want. You then need some hocks and things to get the pipe_winsys and context creation out of the winsys or write code on your own side. I think you might be better of just writing your own winsys. But yes that is a lot of code duplication. If you look at the gallium i915 driver it has one dri winsys and one EGL winsys. Both these share a lot of backend code in a common directory, this part only talks to the DRM. Now I know this is beyond the scope of your gsoc but you could try to talk to the nouveau guys about it. I'd already half planned to look at doing something similar for nouveau at some point actually. Younes, if you decide you could use something similar let me know and I'll try to take a look in the next couple of days while I have a bit of spare time. Ben. dri: gallium/winsys/dri/intel EGL: gallium/winsys/egl_drm/intel backend: gallium/winsys/common/intel_drm Cheers Jakob. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Mesa3d-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM merging?
1) I feel there hasn't been enough open driver coverage to prove it. So far we have done an Intel IGD, we have a lot of code that isn't required for these devices, so the question of how much code exists purely to support poulsbo closed source userspace there is and why we need to live with it. Both radeon and nouveau developers have expressed frustration about the fencing internals being really hard to work with which doesn't bode well for maintainability in the future. OK. So basically what I'm asking is that when we have full-feathered open source drivers available that utilize TTM, either as part of DRM core, or, if needed, as part of driver-specific code, do you see anything else that prevents that from being pushed? That would be very valuable to know for anyone starting porting work. ? I was hoping that by now, one of the radeon or nouveau drivers would have adopted TTM, or at least demoed something working using it, this hasn't happened which worries me, perhaps glisse or darktama could fill in on what limited them from doing it. The fencing internals are very very scary and seem to be a major stumbling block. The fencing internals do seem overly complicated indeed, but that's something that I'm personally OK with taking the time to figure out how to get right. Is there any good documentation around that describes it in detail? I actually started working on nouveau/ttm again a month or so back, with the intention of actually having the work land this time. Overall, I don't have much problem with TTM and would be willing to work with it. Supporting G8x/G9x chips was the reason the work's stalled again, I wasn't sure at the time what requirements we'd have from a memory manager. The issue on G8x is that the 3D engine will refuse to render to linear surfaces, and in order to setup tiling we need to make use of a channel's page tables. The driver doesn't get any control when VRAM is allocated so that it can setup the page tables appropriately etc. I just had a thought that the driver-specific validation ioctl could probably handle that at the last minute, so perhaps that's also not an issue. I'll look more into G8x/ttm after I finish my current G8x work. Another minor issue (probably doesn't effect merging?): Nouveau makes extensive use fence classes, we assign 1 fence class to each GPU channel (read: context + command submission mechanism). We have 128 of these on G80 cards, the current _DRM_FENCE_CLASSES is 8 which is insufficient even for NV1x hardware. So overall, I'm basically fine with TTM now that I've actually made a proper attempt at using it.. GEM does seem interesting, I'll also follow its development while I continue with other non-mm G80 work. Cheers, Ben. I do worry that TTM is not Linux enough, it seems you have decided that we can never do in-kernel allocations at any useable speed and punted the work into userspace, which makes life easier for Gallium as its more like what Windows does, but I'm not sure this is a good solution for Linux. The real question is whether TTM suits the driver writers for use in Linux desktop and embedded environments, and I think so far I'm not seeing enough positive feedback from the desktop side. Also wrt the i915 driver it has too many experiments in it, the i915 users need to group together and remove the codepaths that make no sense and come up with a ssuitable userspace driver for it, remove all unused fencing mechanisms etc.. Dave. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 swizzle W/XYZ interaction strangeness
Am Donnerstag, den 19.01.2006, 22:07 +0100 schrieb Jerome Glisse: Hi Ben, I don't know if you remember but we got a discussion on swizzle issue when we have to write W to a XYZ few month ago. You solved the issue by syncing the XYZ W emit, right (emitting W with the last XYZ emit) ? I recall the discussion. The issue at the time was a misunderstanding on my behalf of how the XYZ and W units interact. It seems that if you emit something like : srcmask(WZX) writemask(X) you have the wrong result but srcmask(WZX) writemask(XY or XZ or XYZ) give right result without syncing. I am update my swizzling table to do so. Does this fail with the current cvs? If so, can you switch on the call to dump_program() at the end of translate_fragment_shader() and post the output as well as the test program? So i wonder if you have anythought on that, or anybody else. Doing so i am able to avoid syncing, this may not be a big save anyway. The syncing is just forcing the XYZ and W components of an instruction into the same ALU slot. There are some cases where this is necessary, namely when there is interaction between the two units. Two cases I know of is when REPL_ALPHA or SWIZZLE_WZY is used. Cheers, Ben. We may miss something here on r300... best, Jerome Glisse --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Fragment program ops + questions
Am Freitag, den 06.01.2006, 17:22 +0100 schrieb Rune Petersen:
- Missing Commit from r300.sf.net:
When trying to Implement the KIL ops I found a commit by Ben Skeggs on
r300.sf.net that was lost in the Mesa tree:
http://sourceforge.net/mailarchive/forum.php?thread_id=7728162forum_id=42268
At the very least the changes for r300_reg.h should be included in Mesa.
That commit fixed quite a few issues, and added all the remaining
opcodes with the exception of the trig opcodes, and LIT. Though, there
are a few things I'd like to clean up in that code soon. Also, The
depth-write support in there didn't work at all if I recall.
- whats with the DP3 op?
if (fpi-DstReg.WriteMask WRITEMASK_W) {
/* I assume these need to share the same alu slot */
sync_streams(rp);
emit_arith(rp, PFS_OP_DP4, dest, WRITEMASK_W,
pfs_zero, pfs_zero, pfs_zero,
flags);
}
emit_arith(rp, PFS_OP_DP3, t_dst(rp, fpi-DstReg),
fpi-DstReg.WriteMask WRITEMASK_XYZ,
t_src(rp, fpi-SrcReg[0]),
t_src(rp, fpi-SrcReg[1]),
pfs_zero, flags);
Okay, if I recall this properly, it would appear to be correct. Though,
some other parts of the code in Mesa CVS may cause it to fail in some
circumstances. In my tests, the code from r300.sf.net CVS seemed to
produce the correct output for DP3.
Why is DP4 called for W and why does DP3 excluding W?
The programmable fragment unit on r300 is split into two separate units.
One of them performs operations on the XYZ components of a register, the
other on the W component. However, there needs to be interaction
between the two units. An ALU instruction looks roughly like this:
FPI0: XYZ opcode + input swizzling
FPI1: XYZ register selection (inputs and output)
FPI2: W opcode + input swizzling
FPI3: W register selection (inputs and output)
So, when you tell r300 to perform a DP4 operation in the W unit. It
takes the XYZ components from the registers mentioned in FPI1, and the W
component from the registers mentioned in FPI3.
Thus, you get the following for the DP4 in the code fragment above:
dot = (X from FPI1) + (Y from FPI1) + (Z from FPI1) + (W from FPI3)
= (X from FPI1) + (Y from FPI1) + (Z from FPI1) + (0 * 0)
.. because all FPI3 is pfs_zero...^^^
= the same result as the DP3 in the XYZ unit.
That's also why the DP3 and DP4 are forced into the same ALU slot as per
the comment. It made register selection a little easier to deal with.
Sorry for the bad explanation, and some of it is possibly incorrect.
It's been a while since I looked at it. For even more information,
check out the comments in r300_reg.h above the fragment program stuff,
it explains this a little more in depth.
Cheers,
Ben Skeggs.
I don't see how it can conform to the specs:
tmp0 = VectorLoad(op0);
tmp1 = VectorLoad(op1);
dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + (tmp0.z * tmp1.z);
result.x = dot;
result.y = dot;
result.z = dot;
result.w = dot;
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 + r300
Am Donnerstag, den 27.10.2005, 19:27 -0400 schrieb Adam K Kirchhoff: FYI, doom3 seems to run with the latest r300 drivers. It's slow, and there are definite texture problems (lots of flickering), but it doesn't crash. You can see a screenshot at http://68.44.156.246/doom3.png I'm not sure what's going on with the flickering, but I recall something similiar when I was messing with S3TC support in my local tree a few months ago. It looks washed out because I had to increase the brightness in gimp to make anything viewable. Interestingly enough, the image looks fine, and doesn't show any of the stuttering. I believe this is because of the fragment program code, I had solved the problem in r300.sf.net cvs but the changes don't appear to have be merged when it was imported into Mesa. I don't really like some parts of the fragment program code, but my time has been rather limited the last few months and I haven't had time to clean it up yet. Ben signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: where is libdrm
Am Montag, den 10.10.2005, 02:41 -0400 schrieb Vladimir Dergachev: Stupid question - what is the official place to get libdrm from ? I read through the webpages (both mesa3d and DRI) and searched on Google, but I dont' seem to find it. It's in drm cvs: http://cvs.freedesktop.org/dri/drm/ Ben. thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ARB_f_p R300 thoughts
Hello, My reasoning behind this is that the destination might well be an output register, which as far as I can tell, there is no way to read from on r300 hardware. It should be possible in the future to handle both cases by checking if dest is a temp or an output and acting accordingly, but I was attempting to keep things simple(ish) until the bugs are ironed out. Also note, that the temporary register is actually freed after it's been used. So we're not really wasting a register. It may present a problem if the dest register hasn't actually been allocated yet, and we run out of temps when trying to allocate it. Cheers, Ben Skeggs. I've been watching the R300 CVS commits, looking forward to a day when we might be able to see good free 3D drivers for today's cards. I have a thought though, which might be fuelled by ignorance of ARB_f_p or of the ATI hardware. Don't hesitate to tell me why I'm wrong... can't FP_OPCODE_SGE and FP_OPCODE_SLT be rewritten to use the destination as a temporary, thereby eliminating the need for a real temporary which may be important for a large/ complex program ? If so it also seems that the remaining FP_OPCODEs already implemented can be rewritten to avoid a temporary in some (most?) cases. Nick. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 testing..
Adam K Kirchhoff wrote: FYI I've had a chance today to test the r300 driver (using a Radeon 9550) with every 3d game and application I have installed. This includes UnrealTournament, ut2004, q3a, RTCW, Rune, Tribes2, Orbz, MarbleBlast (both from GarageGames), neverball, neverputt, NWN, doom3, blender, ppracer, and gltron. There were no lockups and very few rendering errors that I could see. Great to hear! Doom3 refused to launch, just stopping with: - R_InitOpenGL - Setup X display connection dlopen(libGL.so.1) Initializing OpenGL display Using XFree86-VidModeExtension Version 2.2 DGA DirectVideo Mouse (Version 2.0) initialized Free86-VidModeExtension Activated at 800x600 Is that the whole message? Doom3 stops for me with a message saying the required features weren't found. Re-enabling cube maps should allow Doom3 to start. Using the arb renderer, it almost looks correct with the exception of a few things. But it's very slow. The arb2 renderer will most likely look horribly wrong, and will eventually die in r300_fragprog.c due to unimplemented instructions. Mesa also doesn't seem to set fp_instruction-Opcode for the KIL instruction, so what you see with the arb2 renderer may vary from run to run. Performance wise, the driver seems to be on par with the r200 driver. Orbz and NWN are noticably slower. UT2004 is painfully slow, but I'm chalking that up to the S3TC fallback in the games renderer. Blender, which used to crash when opening up a couple files, seems to work flawlessly. I notice that the Blender tool panel doesn't randomly disappear now, which is good. S3TC does seem to be the killer for UT2004. I started porting over the S3TC stuff from the r200 driver a while back, but haven't had a lot of time recently to fix a couple of issues with it. Overall fps doesn't seem to take a huge gain, but the sudden drops to 1-2fps in certain levels (CTF-Faceclassic) disappear when S3TC's enabled. I have most of the remaining ARB_f_p support implemented locally, and some fixes for existing instructions. I needed to overhaul quite a bit of my original code because of some very bad assumptions, so it'll be a week or so before I have time to properly test the changes and commit to cvs. Cheers, Ben. This is on an SMP xeon system, with 1 gig of RAM, running 2.6.12.1 and Debian -unstable. Adam --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Aapo Tahkola wrote:
Someone, I believe it was Aapo, said that they see white lines across the
screen when the framerate is fairly high. I didn't see this up until yesterday
when I had to change from my 9600pro to a 9600XT (I killed the card moving
it between machines somehow).
Are you using SiS based motherboard by any chance?
Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939)
Following patch should fix this at the cost of some speed...
This does indeed seem to correct the problem, and I don't notice a loss
of speed.
glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg
in the
process of applying the patch, so it could be something from there.
What exactly does the patch do? Or is it some magic we don't about yet?
Thanks!
Ben.
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Fri Jun 10 05:46:14 2005
@@ -5631,6 +5631,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
oops.. cc-ing dri-devel this time. Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Dergachev wrote: I tagged yesterday the_perfect_frag snapshot of R300 driver. The code is in CVS at http://r300.sf.net As the name suggests I cannot find visible faults with rendering Quake3 levels. Also, PPRacer shows no artifacts either, at least in the first few levels.. Today's CVS worked quite well on my 9600 Pro playing Legends [1], although the ground was blue when it should've been brown. Also the main menu has a ton of blue stripes across the bottom. Are you using the latest Mesa CVS aswell? UT2004 had similar issues before support for ATI_texture_env_combine3 was added to the texenv generation stuff. The UT2003 demo crashed when I tried to load the DM-Asbestos level, but everything else looked good. The UT2004 demo crashed when trying to start either the AS-Convoy or BR-Colossus levels. The others were pretty much unplayably slow but looked great. After the crash, on the console did you see a message to the effect of Aiii AOS Array count exceeded? I saw this in a number of UT2004 levels. I bumped the maximum from 8 to 16, and AS-Convoy/BR-Colossus seem to start okay. I don't have ut2003 handy to test with, I'll see if ut2003-demo is in portage later on. The Doom 3 demo wouldn't even start. Doom3 retail requires ARB_texture_cube_map, which I've disabled as I don't think we support it properly yet, and it causes some problems with ut2k4. You can re-enable it by uncommenting the line at the top of r300_context.c. Doom3 seems to run okay with the ARB rendering path. Starts okay with R200 and ARB2 paths, but in-game crashes with an unknown fragment program opcode.. According to the output it's an NV_fragment_program opcode, and we're not advertising that extension.. Ben Skeggs. On America's Army, the text was almost unreadable (but I see this on the TODO). Also, the clouds overhead and straight ahead on the first training mission looked like square boxes. Thanks, Donnie 1. http://www.legendsthegame.net/ but it's down atm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCmCOKXVaO67S1rtsRAi3AAKDC/XvUBcre0F5U14gncC9SdjiwQwCfYQnT VCRC3vojRTSZ8eC7zhQSJQQ= =Rv0Z -END PGP SIGNATURE- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Morning,
After playing UT2004 for 10 or so minutes, and then quickly checking
some other
apps known to worn, I see no regressions with either patch.
I'll be putting it through some more rigorous testing as the day
progresses, will
report back if I find anything.
Also, out of interest, what triggered the lockup you saw?
-Ben.
Nicolai Haehnle wrote:
Hi everybody,
I once again tripped upon an R300 lockup (possibly the same one that
everybody's been talking about) and spent the last one and half days
chasing it down.
It turns out that writing the vertex buffer age to scratch registers (the
ones that are written back to main memory) during a 3D sequence is a bad
idea. Apparently, this confuses the memory controller so much that some
part of the engine locks up hard.
The attached patch.out-of-loop-dispatch-age fixes this, at least for me.
The attached patch.remove-userspace-pacifiers removes additional unnecessary
emission of the pacifier sequence from the userspace driver. Userspace
isn't supposed to emit this sequence anyway.
Could everybody please test whether
a) the first patch really does fix the lockups people are seeing and
b) whether combining both the first and the second patch causes any
regressions.
If everything's fine with these patches, I'm going to commit them in a few
days or so.
cu,
Nicolai
Index: drm/shared-core/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.22
diff -u -3 -p -r1.22 r300_cmdbuf.c
--- drm/shared-core/r300_cmdbuf.c 28 May 2005 05:18:42 - 1.22
+++ drm/shared-core/r300_cmdbuf.c 28 May 2005 20:56:59 -
@@ -487,21 +487,19 @@ static __inline__ void r300_pacify(drm_r
}
+/**
+ * Called by r300_do_cp_cmdbuf to update the internal buffer age and state.
+ * The actual age emit is done by r300_do_cp_cmdbuf, which is why you must
+ * be careful about how this function is called.
+ */
static void r300_discard_buffer(drm_device_t * dev, drm_buf_t * buf)
{
-drm_radeon_private_t *dev_priv = dev-dev_private;
-drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
-RING_LOCALS;
-
-buf_priv-age = ++dev_priv-sarea_priv-last_dispatch;
-
-/* Emit the vertex buffer age */
-BEGIN_RING(2);
-RADEON_DISPATCH_AGE(buf_priv-age);
-ADVANCE_RING();
+ drm_radeon_private_t *dev_priv = dev-dev_private;
+ drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
-buf-pending = 1;
-buf-used = 0;
+ buf_priv-age = dev_priv-sarea_priv-last_dispatch+1;
+ buf-pending = 1;
+ buf-used = 0;
}
@@ -518,6 +516,7 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
drm_radeon_private_t *dev_priv = dev-dev_private;
drm_device_dma_t *dma = dev-dma;
drm_buf_t *buf = NULL;
+ int emit_dispatch_age = 0;
int ret = 0;
DRM_DEBUG(\n);
@@ -608,14 +607,15 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
goto cleanup;
}
- r300_discard_buffer(dev, buf);
+ emit_dispatch_age = 1;
+ r300_discard_buffer(dev, buf);
break;
case R300_CMD_WAIT:
/* simple enough, we can do it here */
DRM_DEBUG(R300_CMD_WAIT\n);
if(header.wait.flags==0)break; /* nothing to do */
-
+
{
RING_LOCALS;
@@ -639,6 +639,24 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
cleanup:
r300_pacify(dev_priv);
+
+ /* We emit the vertex buffer age here, outside the pacifier brackets
+* for two reasons:
+* (1) This may coalesce multiple age emissions into a single one and
+* (2) more importantly, some chips lock up hard when scratch registers
+* are written inside the pacifier bracket.
+*/
+ if (emit_dispatch_age) {
+ RING_LOCALS;
+
+ dev_priv-sarea_priv-last_dispatch++;
+
+ /* Emit the vertex buffer age */
+ BEGIN_RING(2);
+ RADEON_DISPATCH_AGE(dev_priv-sarea_priv-last_dispatch);
+ ADVANCE_RING();
+ }
+
COMMIT_RING();
return ret;
Index: r300/r300_render.c
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_render.c,v
retrieving revision 1.87
diff -u -3 -p -r1.87 r300_render.c
--- r300/r300_render.c 19 May 2005 00:03:52 - 1.87
+++ r300/r300_render.c 28 May 2005 20:49:43 -
@@ -489,23 +489,18 @@ static GLboolean r300_run_vb_render(GLco
struct vertex_buffer *VB = tnl-vb;
int i, j;
LOCAL_VARS
Re: R300 swizzle table
Jerome Glisse wrote:
Okay i finaly came over a stupid bug (as all bugs are...).
Thus i commited the table to r300 and here is what look
like swizzle modified emit_arithm (there is some debug
code to test swizzling)...
Note that i changed pfs_reg_t thus swizzling is done
in emit arith and note in t_src. This way we can have
multiple constant as arg for emit_arith and then swizzling
alloc copy const for us (have to add 7 native case to
the table for that).
The reason I was doing swizzling in t_src is that some ARB_f_p opcodes
aren't
native on r300 and we need to emit multiple instuctions to emulate them
(see LRP).
If one of the sources used a non-native swizzle, we'd waste alu
instructions re-doing
the swizzle at each emit. A case where this may be very important is
the SIN/COS
instructions, a document in the Radeon SDK says that COS is 11
instructions..
Also, TEX sources can be swizzled. So putting swizzling/negation into
t_src made sense
in my mind.
If you think that i remove on important field in
pfs_reg tell me. I am wondering if we can drop
the valid field ?
The most important thing missing is the v_cross/s_cross fields. These
are used to
say that the source swizzle depends on the result of the other
instruction stream.
ie. WZYW (v_cross=1), colour instruction depends on result of alpha
instruction,
XYZX (s_cross=1), alpha insn depends on result of colour instruction.
WZYX (v_cross=1,
s_cross=1), both depend on opposite stream.
This allows for an extremely primitive form of instruction reordering so
that we make
use of the split xyz/w units, instead of leaving a whole load of NOPS
when an ARB_f_p
instruction only writes xyz or w.
The valid field comes in useful occasionally when testing some things.
The has_w field
was only used by my swizzling code to say whether or not the W coord had
to be copied
over to the resulting swizzle, so you could probably drop that if you
don't need it for
your code.
I haven't yet done indivual or global neg but as i said
i think that the best solution is to first swizzle and then
do a
MAD t, -t, 1, 0 with appropriate write mask.
Anyway once Keith commited your patch and you
commited your change in r300, i will commit change
to use table with individual neg support...
Cool. I'll have a closer look at your code when I get home again in 12
or so hours.
Cheers,
Ben Skeggs.
Jerome Glisse
typedef struct _pfs_reg_t {
enum {
REG_TYPE_INPUT,
REG_TYPE_OUTPUT,
REG_TYPE_TEMP,
REG_TYPE_CONST
} type:2;
GLuint index:6;
GLuint xyzw:12;
GLuint negate:4;
GLboolean has_w:1;
GLboolean valid:1;
} pfs_reg_t;
GLuint swizzle( struct r300_fragment_program *rp,
pfs_reg_t swz_src )
{
GLuint src[3] = { 0, 0, 0 };
GLuint inst[4] = { 0, 0, 0, 0 };
GLuint i, xyz, w, j;
pfs_reg_t tmp;
switch (swz_src.type) {
case REG_TYPE_INPUT:
src[0] = rp-inputs[swz_src.index];
break;
case REG_TYPE_TEMP:
src[0] = rp-temps[swz_src.index];
src[0] = swz_src.index;
rp-used_in_node |= (1 src[0]);
break;
case REG_TYPE_CONST:
src[0] = swz_src.index;
break;
default:
ERROR(invalid source reg\n);
return 0;
}
/* Allocate temp reg for swizzling */
tmp = get_temp_reg(rp);
src[1] = tmp.index;
xyz = swz_src.xyzw 511;
w = (swz_src.xyzw 9) 7;
printf(w : %d\n,w);
inst[2] = r300_swz_srca_mask[0][w] |
(R300_FPI2_ARGA_ONE R300_FPI2_ARG1A_SHIFT) |
(R300_FPI2_ARGA_ZERO R300_FPI2_ARG2A_SHIFT) |
R300_FPI0_OUTC_MAD;
inst[3] = src[0] |
R300_FPI3_SRC1A_CONST |
R300_FPI3_SRC2A_CONST |
(src[1] R300_FPI3_DSTA_SHIFT);
inst[3] |= R300_FPI3_DSTA_REG;
for (i = 0; i r300_swizzle[xyz].length; i++) {
inst[0] = r300_swizzle[xyz].inst[(i 1)];
inst[1] = r300_swizzle[xyz].inst[(i 1) + 1];
inst[1] |= src[r300_swizzle[xyz].src[i]];
inst[1] |= src[1] R300_FPI1_DSTC_SHIFT;
rp-alu.inst[rp-v_pos].inst0 = inst[0];
rp-alu.inst[rp-v_pos].inst1 = inst[1];
rp-alu.inst[rp-s_pos].inst2 = inst[2];
rp-alu.inst[rp-s_pos].inst3 = inst[3];
rp-v_pos += 1;
rp-s_pos += 1;
j = rp-v_pos rp-s_pos ? rp-v_pos : rp-s_pos;
if (j rp-alu.length) {
rp-alu.length++;
rp-node[rp-cur_node].alu_end++;
}
}
return src[1];
}
static void emit_arith( struct r300_fragment_program *rp
Re: [R300] new snapshot ?
Jerome Glisse wrote: On 5/19/05, Keith Whitwell [EMAIL PROTECTED] wrote: Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? Sounds like a good idea. Why not :) So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... I think to few of us have an access to mesa cvs (at leat i didn't have one), anyway i could ask one. But there is still missing parts. I would like to know if anyone know what is still not working and thus do a to do list of that... What i see missing is : (i may not see everythings :-) -deeper testing of tcl program generated with mesa -tex env -fragment program Also, I think there's still some weirdness with a couple of texture formats, namely GL_ALPHA and GL_LUMINANCE_ALPHA. This is clearly seen in Mesa/progs/demos/texenv.c. Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Does ... work ? -z offset -stencil Right now i am on pixel shader after doing some test i don't think we can use a similar stuff like i915 emit arithm, i915 hardware are far more easier to program than r300. I am coding another approach an hope to have it done by the end of this week. I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs. I was planning on commiting this soon, but you may have a better approach than I took so I'll wait a bit. Ben Skeggs. Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Gemeinsame Unterverzeichnisse: r300.old/CVS und r300/CVS. diff -Nu r300.old/Makefile r300/Makefile --- r300.old/Makefile 2005-04-24 19:08:31.0 +1000 +++ r300/Makefile 2005-05-19 03:24:11.0 +1000 @@ -37,6 +37,7 @@ r300_texstate.c \ r300_texprog.c \ r300_vertexprog.c \ +r300_fragprog.c \ r300_shader.c \ r300_maos.c # \ diff -Nu r300.old/r300_context.c r300/r300_context.c --- r300.old/r300_context.c 2005-05-19 23:50:38.0 +1000 +++ r300/r300_context.c 2005-05-19 23:47:41.0 +1000 @@ -80,7 +80,9 @@ GL_ARB_texture_mirrored_repeat, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, - //GL_ARB_fragment_program, +#if USE_ARB_F_P == 1 + GL_ARB_fragment_program, +#endif GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, @@ -325,7 +327,19 @@ ctx-Const.MaxVertexProgramLocalParams=256; // r420 ctx-Const.MaxVertexProgramEnvParams=256; // r420 ctx-Const.MaxVertexProgramAddressRegs=1; - + +#if USE_ARB_F_P + ctx-Const.MaxFragmentProgramTemps = PFS_NUM_TEMP_REGS; + ctx-Const.MaxFragmentProgramAttribs = 11; /* copy i915... */ + ctx-Const.MaxFragmentProgramLocalParams = PFS_NUM_CONST_REGS; + ctx-Const.MaxFragmentProgramEnvParams = PFS_NUM_CONST_REGS; + ctx-Const.MaxFragmentProgramAluInstructions = PFS_MAX_ALU_INST; + ctx-Const.MaxFragmentProgramTexInstructions = PFS_MAX_TEX_INST; + ctx-Const.MaxFragmentProgramInstructions = PFS_MAX_ALU_INST+PFS_MAX_TEX_INST; + ctx-Const.MaxFragmentProgramAddressRegs = 0; /* and these are?? */ + ctx-_MaintainTexEnvProgram = GL_TRUE; +#endif + driInitExtensions(ctx, card_extensions, GL_TRUE); radeonInitSpanFuncs(ctx); diff -Nu r300.old/r300_context.h r300/r300_context.h --- r300.old/r300_context.h 2005-05-19 23:50:38.0 +1000 +++ r300/r300_context.h 2005-05-19 23:47:41.0 +1000 @@ -47,6 +47,8 @@ #include colormac.h #include radeon_context.h +#define USE_ARB_F_P 1 + struct r300_context; typedef struct r300_context r300ContextRec; typedef struct r300_context *r300ContextPtr; @@ -83,7 +85,11 @@ and pixel_shader structure later on */ #define CARD32
Re: [R300] new snapshot ?
Jerome Glisse wrote: I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs. I was planning on commiting this soon, but you may have a better approach than I took so I'll wait a bit. I have tried a similar approach at first but as swizzle appear it looks awful, i haven't take a deeper look at the way you handle it but you have a bunch of if test like i got in my first version. You certainly have done cleaner version than my first attempt thought. Anyway now what i have is the stupid way of having a table for all swizzle case, just for the x,y,z component as w is in sep an easier reg. Thus i got two tab one for xyz to FPI0_SRC conv which have a special value for not native format, this special value in an index in the second tab where i got all the code for all differents cases (64 cases less 7 of native format). This consumes few bytes about 1ko... I use a similar approach. v_swiz contains all the native r300 swizzle values, aswell as a couple of cases where we have to handle them specially. The non-native cases have v_swiz-native set to GL_FALSE. What I do is firstly loop through checking for matches of XYZ. If we match all three components, the code will return a pfs_reg_t with v_swz/s_swz set to a native type. Otherwise, we continue looping through the different outmasks doing multiple emits to another temp until we have the desired value. Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? The code is only translated once. In the case of the texenv stuff, whenever it needs to be regenerated Mesa will call r300ProgramStringNotify to tell us that the program has changed. Anyway other part of the code is basicly the same, yours is in a more advanced state than mine thus we should use yours... Anyone have strong feeling on this swizzle thing ? Or even an magic idea with a magic bitwise formula :) One other interesting feature is reuse of temp register at some point i was thinking of adding a free_temp function and having a stack of free register. Then get_temp first take from the stack if not empty, or use a new temp if empty. This get/free approach is usefull with swizzling where you know that you will use a temps register only for 1 instruction. But there may be case where you reuse the same swizzled src. I once had this in the code, but ended up stripping it down to iron out some bugs. Now that I know that it mostly works correctly, I should be able to add this back in easily enough. Rather than using a stack, I'm using a bitfield to track register allocations. Freeing a register is as easy as setting the bit to 0. Care must be taken not to cause texture indirections by reusing an already used temp as the destination for a TEX instruction (that's what rp-used_this_node is/was for) I am wondering if you emit_const_swizzle may not consume all const if say you have an const which is used in all of the 64 possibles swizzle... I may have miss something on that thought. But if we know that we will only use the const in a swizzled format then your solution is the best. No, you haven't missed anything. This was another case where I quickly hacked something up. Constant swizzles should/could be handled exactly the same as temp swizzles. In the swizzling code you just have to be careful that reg-type is set correctly depending on whether or not it's a native swizzle. I got other idea on optimizing this swizzling in program translation (basicly tracking operand). But this are maybe useless optimization for time being... I've thought of similar things, but haven't attempted anything yet. I also need to take another look at the generated code, to make sure that combining the xyz and w instuction streams is working as I intended. When I first integrated my test code into r300_dri it was, but I've changed much since then. Cheers, Ben Skeggs. Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https
Re: [R300] new snapshot ?
Jerome Glisse wrote:
I use a similar approach. v_swiz contains all the native r300 swizzle
values,
aswell as a couple of cases where we have to handle them specially. The
non-native cases have v_swiz-native set to GL_FALSE.
I saw that in code but you still got a loop and test case, your
approach is well thinked. But i think it may be hard to understand
say if you look at it in 2 or 3 month.
Thus the only + arguments for a simple 2tab translation i
propose is that it the easiest thing to understand, moreover
you can easily optimize some swizzling case and don't bother
too much on other... But beside the understanding
of your mixed approach haven't a strong opinion on which solution is the
best...
The code is only translated once. In the case of the texenv stuff, whenever
it needs to be regenerated Mesa will call r300ProgramStringNotify to tell
us that the program has changed.
This why i think tab lookup speed isn't really revealent in
selecting this. I will try to adapt my swizzle function
to your code (shouldn't be difficult) thus you can see it.
Bascily arg checking in emit arith look like this :
id = reg MASK_XYZCHANNEL
reg_fpi0_mask = tab1[id];
if (reg_fpi0_mask ^ ffe0 ) {
swizzle - copy tab2[id5] - r300_instruct
t = get_temp
for itab2[id5].length
r300_instr[p-i] |= t
}
Just a memcpy of instruction and a small loop
to set the correct temp reg allocated.
Well, I'm in mixed minds about this myself now. But if you have a way
to gain extra
speed out of this without consuming a heap of RAM, I'm all for it :)
Extra speed could be useful, as some programs may have a lot of swizzles
per-frame (UT2004
has a few when MaxTextureUnits is set to 8 in ut2004.ini) and every
extra bit helps.
Care must be taken not to cause texture indirections by reusing an
already
used temp as the destination for a TEX instruction (that's what
rp-used_this_node
is/was for)
Yes, i saw this possible issue but didn't think too much on
solution to handle it, i will give a deeper look to your code
this evening.
I've attached another patch (applies on top of the last one) which
/should/ take
care of this, and handle the case where a program does a TEX directly to an
output. It also free's up temps in the cases where we need one for a
swizzle, or
an LRP.
What I'd like to be able to do is re-use temps used by the Mesa program,
and also
to free-up the hardware temp that a Mesa INPUT uses once they're no
longer needed.
We'd need to find out when the temp/input was last used so we didn't
destroy it
pre-maturely.
Should be easy enough to do, as my code already pre-parses the Mesa
program. I
originally considered this a thing I needed to fix. But it could be
useful for some things.
No, you haven't missed anything. This was another case where I quickly
hacked
something up. Constant swizzles should/could be handled exactly the same as
temp swizzles. In the swizzling code you just have to be careful that
reg-type is
set correctly depending on whether or not it's a native swizzle.
I was thinking of tracking constant and see if they are always used
swizzle. If so easier to emit the const swizzled like you do.
As i said this is maybe a to advanced and complex optimization which
may involve complex tracking of operand in the program.
You could possibly do this for some cases right now. In t_src you'd
need to skip
the emit_const4fv for constant sources if they're swizzles, and call
swizzle_const
instead. This would eliminate some of them.
The patch I attached doesn't call swizzle_const at all, instead, it uses
the same
method as temps do. I didn't see anything too nasty in ut2004 from
doing this.
I didn't test the patch in great detail, so there's probably something I
missed :/
Ben Skeggs.
Jerome Glisse
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12alloc_id344op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--- diff/r300/r300_fragprog.c 2005-05-19 04:23:09.0 +1000
+++ r300_wip/r300/r300_fragprog.c 2005-05-20 03:21:23.0 +1000
@@ -172,10 +172,21 @@
rp-hwreg_flag |= (1 r);
rp-hwreg_used |= (1 r);
-
+
return r;
}
+static void free_hw_temp(struct r300_fragment_program *rp, int idx)
+{
+ rp-hwreg_flag = ~(1idx);
+}
+
+static void free_temp(struct r300_fragment_program *rp, int idx)
+{
+ free_hw_temp(rp, rp-temps[idx]);
+ rp-temp_flag = ~(1idx);
+}
+
static pfs_reg_t emit_const4fv(struct r300_fragment_program *rp, GLfloat *cp)
{
pfs_reg_t r = pfs_default_reg;
@@ -209,6 +220,23 @@
return r;
}
+static pfs_reg_t get_temp_tex(struct r300_fragment_program *rp
Re: r300 patch to fix macro in r300_context.h
Jeff Smith wrote: This patch fixes a bug that was causing the Mesa compile for r300 to bail on me. -- Jeff Smith __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com This has been fixed in current cvs, anonymous may not have caught up yet. Thanks, Ben Skeggs. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: licenses, R300 code, etc
This needs approval from everyone who contributed to R300 - please let me know ! Fine by me. --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
Jerome Glisse wrote: Seems like everyone's working on the same thing. I've just committed a file which implements most of this internally in Mesa. I've got a few other commits to make before it can be turned on, but it should be pretty much the facility you're looking for. Btw you are not working on same things for pixel shader (texture filtering, multi-texture, ...) ? Thus doing all the code we need :) This would indeed be useful, as currently the i915 and r300 drivers could both use common code for the fragment pipeline. I'm almost certain that drivers for future hardware will also benefit from having this functionality inside Mesa. Cheers, Ben Skeggs. Jerome Glisse --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 pixel shader
I've been doing quite a bit of work towards getting rid of the EASY_PFS_INSTR and co. macros. My aim is to have a function similar to i915's i915_emit_arith, that will handle swizzling/negation transparently. If all goes to plan, I should have something that works okay in the next couple of days. r300 doesn't support arbitrary swizzling in fragment programs like it does for vertex programs. Unsupported swizzles need to be done in multiple instructions. As for the SRC0A in FPI0, The W component is replicated into the XYZ registers somehow, but I'm not exactly sure what components W gets copied into. Cheers, Ben Skeggs. Jerome Glisse wrote: Hi, I was playing with pixel shader, trying to improve support of texenv co... But i didn't success to find a way to do swizzle. If i ask for SRC0A in FPI0 is the A component replicated ? Anyone so far played with all that ? By the way i take a quick look to i915 code, and like Keith said maybe (i think he says something about that in a previous mail :)) we could have something generic enought for graphics cards with pixel shader ? Thus having less code to debug do... best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Multitexturing support added
G'Day, I've just committed the start of multitexturing support to CVS. The code works for me, but I've left the old code intact, and can be re-enabled by changing a couple of ifdefs in r300_state.c. Here's what remains to be done: 1. Implement the remaining texenv functions, I believe I left out GL_BLEND/GL_DECAL and GL_COMBINE. The ones I did implement were the simple ones, it's almost 5am so I decided not to tackle the rest just yet. 2. Possibly fix the current texenv's. I'm not entirely sure if they're done correctly, I need to study the gl spec a bit more. 3. Currently, only 5 texture units can be enabled, MAX_AOS_ARRAYS needs to be increased for this. 4. Find a better way of describing instructions than EASY_PFS_INSTRx 5. Clean up some bits of the code There's an issue where the first frame isn't drawn correctly, I noticed this behavior with the old code also. You can see this by running the Mesa texenv demo, the first box appears to have recieved the wrong texcoords. A possibly related issue can be seen when you enable units 0,1 and 3 in the multiarb demo, the third texture is a little messed up. Anyhow, I should go sleep now. Have fun! Cheers, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] q3demo = _no_ artifacts
Rune Petersen wrote: Hi, I gave q3demo a try and to my surprise there was no artifacts. This must have been fixed by one of the many changes. Does this only work for me? Or is it time to update the status page? I can't actually run q3 anymore to test it (no ioctl32), but I no longer get artifacts in ut2004-demo. I believe that it was elts being implemented which corrected this, but I could be wrong. Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] q3demo = _no_ artifacts
Vladimir Dergachev wrote: Also I believe we are still not doing correct things in many cases, especially as pixel shaders are concerned (no Gourad, multitexturing messed up). I believe I now have a good understanding of how to implement multitexturing properly, I could be wrong. But I'll find out very shortly. I'm working on some code now that I hope will make (at least) the mesa multiarb demo render correctly. Also, Is there anybody working on figuring out the missing texture formats? The problems with the texenv demo aren't only caused by incorrect texenv's, but most of the used texture formats are missing. I believe we have all the information about texture formats we need in r300_reg.h. I did not put the strings for other texture formats because I did not have anything to test them with and be sure of the result. It is easier to get the format right when you are adding it (and know which entry you are messing is), rather than add it blindly and then find out that a couple of components are in the wrong order. I'm not entirely sure of how to correctly define the texture formats. While I was messing with texenv's I made texenv.c printf what format it was using, and changed the WARN_ONCE into a printf to find out all the missing formats. I ended up adding something for entry 15, which corresponded to when texenv.c was using GL_ALPHA. I added R300_EASY_TX_FORMAT(W, X, X, X, ALPHA_1CH) to get the result to *look* correct, but I don't know if it *is* correct. Ben Skeggs. best Vladimir Dergachev Cheers, Ben Skeggs. best Vladimir Dergachev Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] q3demo = _no_ artifacts
Vladimir Dergachev wrote: On Sat, 5 Mar 2005, Ben Skeggs wrote: Rune Petersen wrote: Hi, I gave q3demo a try and to my surprise there was no artifacts. This must have been fixed by one of the many changes. Does this only work for me? Or is it time to update the status page? I can't actually run q3 anymore to test it (no ioctl32), but I no longer get artifacts in ut2004-demo. I believe that it was elts being implemented which corrected this, but I could be wrong. The rendering quality had indeed improved. I still get artifacts in quake3, also the menu does not have flaming Quake string on top. However, q3demo appears to be simpler than quake3 and the particular levels easier on the renderer. For example the same dock level displays fine in both q3demo and quake3, but nearby levels often give me white walls artifact, with textures appearing and disappearing on them depending on distance and angle of view. I also see dithering see-through objects while they should be opaque (like the pedestal) Also I believe we are still not doing correct things in many cases, especially as pixel shaders are concerned (no Gourad, multitexturing messed up). I believe I now have a good understanding of how to implement multitexturing properly, I could be wrong. But I'll find out very shortly. I'm working on some code now that I hope will make (at least) the mesa multiarb demo render correctly. Also, Is there anybody working on figuring out the missing texture formats? The problems with the texenv demo aren't only caused by incorrect texenv's, but most of the used texture formats are missing. Cheers, Ben Skeggs. best Vladimir Dergachev Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
Paul Mackerras wrote:
Jerome Glisse writes:
If you find the guilty commit let me know :)
It appears to be this code in r300_state.c (line 1625):
#if 0
/* textures enabled ? */
if(rmesa-state.texture.tc_count0){
rmesa-state.vertex_shader=SINGLE_TEXTURE_VERTEX_SHADER;
} else {
rmesa-state.vertex_shader=FLAT_COLOR_VERTEX_SHADER;
}
#endif
r300GenerateSimpleVertexShader(rmesa);
If I remove the r300GenerateSimpleVertexShader call and change the #if
0 to 1, it works again (well, as well as it did before :).
Paul.
Do you still see the same breakage with vertex buffer mode? The textures in
neverball are broken for me in immediate mode with the latest cvs.
Cheers,
Ben Skeggs.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Radeon 9550 Problems
Hello, You need to use the drm that's in r300_driver/drm. The one that comes with the kernel doesn't have all the needed functions. Cheers, Ben. [EMAIL PROTECTED] wrote: Hi, I'm new to DRI development but am interested in helping with the r300 driver. I am trying to get the driver working with my Radeon 9550 and I have glxinfo reporting that direct rendering is enabled and the OpenGL renderer string is Mesa DRI R300 20040924 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL, but glxgears exits almost immediately with the last message it prints out being drmRadeonCmdBuffer: -22 (exiting). I am running a 2.6.11-rc5 kernel using the DRM modules that come with it (I can't get the DRM modules from CVS to load with a 2.6.10 kernel), the latest Xorg, Mesa, and r300_driver sources from anonymous CVS as of about 11am today (2005-03-01). Everything has been compiled against glibc 2.3.4 using gcc 3.4.3. I'm not using merged-fb nor is the kernel radeon framebuffer module loaded. The error is identical regardless of whether I have immediate mode or VB mode enabled (I don't think it is making it that far in the driver code before exiting...). I have attached the output from glxgears with LIBGL_DEBU=verbose and RADEON_DEBUG=all. Any ideas, or advice for debugging this problem? - Brian __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen 0) libGL: OpenDriver: trying /home/satyr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/satyr/.drirc: No such file or directory. r300AllocTexObj( 0x805b000, 0x807acd8 ) r300AllocTexObj( 0x805b1d0, 0x807b2f0 ) r300AllocTexObj( 0x807b908, 0x807bad8 ) r300AllocTexObj( 0x807c0f0, 0x807c2c0 ) r300AllocTexObj( 0x807c8d8, 0x807caa8 ) r300AllocTexObj( 0x808b908, 0x808bad8 ) r300AllocTexObj( 0x808c0f0, 0x808c2c0 ) r300AllocTexObj( 0x808c8d8, 0x808caa8 ) r300AllocTexObj( 0x808d0c0, 0x808d290 ) r300AllocTexObj( 0x808d8a8, 0x808da78 ) Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=16 Allocating 284420 bytes command buffer (max state is 11140 bytes) r300ResetHwState r300Enable( GL_DEPTH_TEST = GL_FALSE ) mtu=8 TX_ENABLE: max_texture_unit=-1 r300Enable( GL_POLYGON_OFFSET_POINT = GL_FALSE ) *WARN_ONCE* File r300_state.c function r300Enable line 516 Don't know how to enable polygon offset point/line. Help me ! *** r300Enable( GL_POLYGON_OFFSET_LINE = GL_FALSE ) r300Enable( GL_POLYGON_OFFSET_FILL = GL_FALSE ) R200 begin tcl fallback User disable radeonMakeCurrent ctx 0x805eca8 r300ResetHwState r300Enable( GL_DEPTH_TEST = GL_FALSE ) Enabling VB-ObjPtr Enabling VB-ColorPtr[0] RR[0] - sz=4, reg=0, fmt=1 -- st=4, of=0x RR[1] - sz=4, reg=1, fmt=3 -- st=4, of=0x mtu=8 TX_ENABLE: max_texture_unit=-1 r300Enable( GL_POLYGON_OFFSET_POINT = GL_FALSE ) r300Enable( GL_POLYGON_OFFSET_LINE = GL_FALSE ) r300Enable( GL_POLYGON_OFFSET_FILL = GL_FALSE ) End radeonMakeCurrent r300Enable( GL_CULL_FACE = GL_TRUE ) r300Enable( GL_LIGHTING = GL_TRUE ) r300Enable( GL_LIGHT0 = GL_TRUE ) r300Enable( GL_DEPTH_TEST = GL_TRUE ) r300Enable( GL_NORMALIZE = GL_TRUE ) r300ResetHwState r300Enable( GL_DEPTH_TEST = GL_TRUE ) Enabling VB-ObjPtr Enabling VB-ColorPtr[0] RR[0] - sz=4, reg=0, fmt=1 -- st=4, of=0x RR[1] - sz=4, reg=1, fmt=3 -- st=4, of=0x mtu=8 TX_ENABLE: max_texture_unit=-1 r300Enable( GL_POLYGON_OFFSET_POINT = GL_FALSE ) r300Enable( GL_POLYGON_OFFSET_LINE = GL_FALSE ) r300Enable( GL_POLYGON_OFFSET_FILL = GL_FALSE ) r300Clear: all=1 cx=0 cy=0 cw=300 ch=300 r300ClearBuffer: back buffer (26,9 300x300) Reemit state after flush (from r300ClearBuffer) r300EmitState Begin reemit state Begin dirty state r300EmitState r300ResetHwState r300Flush r300FlushCmdBufLocked from r300Flush - 1 cliprects Syncing in r300FlushCmdBufLocked (from r300Flush) drmRadeonCmdBuffer: -22 (exiting) --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] DRM perturbation
Vladimir Dergachev wrote: [snip] Thus, could everyone with changing they have not committed yet to *DRM* driver but plan to please let me know ? Also any comments, reservations, etc. One reason I am so eager for this is that there have been quite a few fixes to the DRM driver, including tiling support. Sounds great to me. I've got nothing that changes the drm currently, just been figuring out how the rest of the driver (everything except vertex data emits) works. Hopefully, the updated drm will allow me to stay in X for a while without encountering the WaitForSomething(): select: errno=22 error I was having with the current drm. One question about tiling, will this cause any problems with the current r300 code? Or is it something completely unrelated? Cheers, Ben Skeggs. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
Nicolai Haehnle wrote: Hi everybody, As reported earlier, I had a perfectly repeatable lockup in VB mode that always happened after the exact same number of frames in glxgears. I can't explain everything about the lockup, mostly because I still don't know what the two registers in the begin3d/end3d sequence actually mean, but here's what I know: --snip-- Thankyou for the explanation! 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 so that r300_vb_run_render() is called). I want to be really sure that this fixes it for other people as well (after all, there may be other causes for lockups that haven't occured on my machine yet), and that there are no regressions for those who already had working VB mode. I wasn't able to produce lockups before this patch (with an RV350 AP). I didn't notice any regressions with you're patch. The most stressful app that I can run is ut2004-demo, and didn't see any lockups after running around DM-Rankin for 20-30 minutes, I also ran glxgears,tuxracer and neverball briefly without problems. Once we can be fairly certain that VB mode is stable (i.e. crash and lockup-free), let's talk about removing any mention of the begin3d and end3d sequence from the userspace driver. This is really far too subtle an issue to allow userspace to mess with it. This counts for the X server as well - if anybody feels like implementing Render acceleration, which I doubt at this stage, please leave the begin3d/end3d handling to the kernel module, as it's the only instance that really knows what's going on. I still have a 100% reproducable bug which I need to find the cause of, but time is once again a problem for me. If I move a window over the top of a glxgears window my machine locks up immediately, but sysrq still works fine. Hopefully I'll have time to take a look at this on Sunday. Cheers, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
Hello again. I still have a 100% reproducable bug which I need to find the cause of, but time is once again a problem for me. If I move a window over the top of a glxgears window my machine locks up immediately, but sysrq still works fine. I just discovered (and should've checked before), that I can ssh in and successfuly kill glxgears, then X returns to normal. I can have a partially covered glxgears window and everything is fine, but as soon as the entire window (not incl. window decorations) is covered, it seems that the 2d driver is unable to update the screen. Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
Nicolai Haehnle wrote: On Friday 18 February 2005 16:03, Keith Whitwell wrote: Ben Skeggs wrote: I still have a 100% reproducable bug which I need to find the cause of, but time is once again a problem for me. If I move a window over the top of a glxgears window my machine locks up immediately, but sysrq still works fine. I just discovered (and should've checked before), that I can ssh in and successfuly kill glxgears, then X returns to normal. I can have a partially covered glxgears window and everything is fine, but as soon as the entire window (not incl. window decorations) is covered, it seems that the 2d driver is unable to update the screen. I think some of the other drivers do a 'sched_yeild()' or 'usleep(0)' in the zero cliprect case to get away from this sort of behaviour. Well, I can reproduce this bug and I tracked it down. There are a number of problems here, and they all have to do with DMA buffer accounting. The first (trivial) problem is that nr_released_bufs was never reset to 0. I've already fixed that in CVS. The real problem is that the following situation can occur when we have zero cliprects: 1. The command buffer contains a DISCARD command for a DMA buffer. 2. We simply drop that command buffer because there are no cliprects, i.e. nothing can be drawn. 3. As a consequence, DMA buffers aren't freed. 4. The rendering loop continues even though DMA buffers have been leaked, which eventually causes all DMA buffers to be exhausted, and this causes an infinite loop in r300RefillCurrentDmaRegion. The root cause is that we drop the command buffers with the DISCARD. I can see two possible solutions to this problem: 1. Wait until we have a cliprect again before submitting command buffers. 2. Submit command buffers even when we have no cliprects. The kernel module would basically ignore everything but the DISCARD commands. 3. Something else? I'm still rather new at this, so forgive me if this is a bad suggestion. How about going with option 2, but only submitting the command buffer anyway if nr_released_bufs != 0. Would this cause any unwanted side effects? It seems better than just always submitting buffers with no cliprects anyhow. Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
oops, I hit reply, not reply all.. cc-ing dri-devel this time. jan kreuzer wrote: Hi i tested nwn with latest cvs-snapshot of r300. It runs, however the screen is totally weird. I uploaded an screenshot of what the screen looks like to http://www.freephotoserver.com/files/img14048784_50868694.jpg . nwn probably uses something which requires elts to be supported (ie. glDrawElements). The latest cvs snapshot has made a start on this, but more information is needed. I've had some success with ut2004 by putting the indices into the command buffer, but ultimately this is not how we want to do it. I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Is this with vertex buffers turned on? If so, can you cause a lockup by moving a window over the top of the glxgears window? This is the only way I can cause a lockup with the vertex buffer code. I'm using xorg cvs from 1-2 days before the dlloader changes. Cheers, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Jan Kreuzer wrote: nwn probably uses something which requires elts to be supported (ie. glDrawElements). The latest cvs snapshot has made a start on this, but more information is needed. I've had some success with ut2004 by putting the indices into the command buffer, but ultimately this is not how we want to do it. As far as i could see from the cvs-logs the elts thing was added 17 hours ago, however i tested nwn earlier and the screenshots looked the same. So it seems that this change is not responsible for this weird looking. I wasn't saying that this change broke it, I meant that when completed, applications which use glDrawElements etc, should render correctly, rather than having some random polygons on the screen. I'm not even sure if this is the cause of the nwn rendering errors, it could be something else completely. But, it does look like the same type of problem which ut2004-demo has. Cheers, Ben Skeggs. However i now can turn on reflection in neverball without an slowdown (before i had an slowdown). I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Is this with vertex buffers turned on? If so, can you cause a lockup by moving a window over the top of the glxgears window? This is the only way I can cause a lockup with the vertex buffer code. I'm using xorg cvs from 1-2 days before the dlloader changes. Hmm i must test this with an earlier snapshot, then i will report back. Greetings Jan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Hello Adam, You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Hmmm... I made those changes. The game started up and loaded a level without problems. Unfortunately, within a few seconds Q3A had locked up. I could still ssh in and reboot though. I'm really quite thrilled that complete system lockups seem to be a thing of the past. Anyone want to comment on if we will see a day when an application which locks up can just be killed and X returns to normal? :-) Is the Q3A lockup repeatable 100% of the time? I've been attempting to find the source of a lockup Vladimir reported, which seems to be related to mouse movement, but I haven't been able to reproduce it yet. No problems. I have a few others I can try (ie. doom3, ut2004), too. Adam ut2004 demo will start after messing with the config file options a bit, and disabling the multitexture fallback (ut2004-demo doesn't seem to respect it's MaxTextureUnits option). However, it seems to be horribly corrupted in game, much the same as quake3 is when r_ext_compiled_vertex_array is set. I haven't tried doom3 yet, and won't be able to now until there is a 64-bit version, or the drm has support for 32-bit clients. Thanks again! Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Hello, These are the games I've tried with the latest CVS from this afternoon: Neverputt and neverball play, but some debug output gets displayed: --snip-- :p You can get neverball working much more smootly by switching everything to low in the menu screen. Ignore the warn once messages, they're more of a reminder of what needs to be done still. Chromium works. UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx-Texture.Unit[i].Enabled I believe we're still only letting one texture pass through the pipeline, I'm not sure why the fallback is causing a segfault though. Q3A displays similar problems in the menu screen, and level loading screen, but dies once the level is loaded with the same Texture.Unit error. Quake2 is similar. You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Frankly, I'm thrilled at the handful of games that are now working! Adam Great! Thankyou for testing on some (afaik) untested programs. Cheers, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 vb path
Hello,
I've attached a patch with a port of the r200 vertex buffer code for the
r300 driver.
The performance of the vertex buffer codepath is now roughly the same as the
immediate path, and tuxracer now seems to be rendered almost correctly.
Vladimir, I haven't found a way that I can directly call the
r200/radeon's discard buffer
command from r300_dri, so this patch still includes the drm additions.
Perhaps someone
could help me out with this one?
Could the people testing r300_dri test this if they have the time? And
Vladimir, can you
let me know if you want me to commit this, or if it needs more work.
Thanks,
Ben Skeggs.
diff -Nur r300_driver/drm/shared-core/r300_cmdbuf.c
r300_driver_wip/drm/shared-core/r300_cmdbuf.c
--- r300_driver/drm/shared-core/r300_cmdbuf.c 2005-01-08 13:46:34.0
+1100
+++ r300_driver_wip/drm/shared-core/r300_cmdbuf.c 2005-02-11
05:10:16.185196992 +1100
@@ -354,16 +354,37 @@
return 0;
}
+static void r300_discard_buffer(drm_device_t * dev, drm_buf_t * buf)
+{
+drm_radeon_private_t *dev_priv = dev-dev_private;
+drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
+RING_LOCALS;
+
+buf_priv-age = ++dev_priv-sarea_priv-last_dispatch;
+
+/* Emit the vertex buffer age */
+BEGIN_RING(2);
+RADEON_DISPATCH_AGE(buf_priv-age);
+ADVANCE_RING();
+
+buf-pending = 1;
+buf-used = 0;
+}
+
+
/**
* Parses and validates a user-supplied command buffer and emits appropriate
* commands on the DMA ring buffer.
* Called by the ioctl handler function radeon_cp_cmdbuf.
*/
int r300_do_cp_cmdbuf(drm_device_t* dev,
+ DRMFILE filp,
drm_file_t* filp_priv,
drm_radeon_cmd_buffer_t* cmdbuf)
{
drm_radeon_private_t *dev_priv = dev-dev_private;
+drm_device_dma_t *dma = dev-dma;
+drm_buf_t *buf = NULL;
int ret;
DRM_DEBUG(\n);
@@ -375,6 +396,7 @@
}
while(cmdbuf-bufsz = sizeof(drm_r300_cmd_header_t)) {
+ int idx;
drm_r300_cmd_header_t header;
if (DRM_GET_USER_UNCHECKED(header.u, (int __user*)cmdbuf-buf))
{
@@ -431,6 +453,26 @@
ADVANCE_RING();
}
return 0;
+
+ case R300_CMD_DMA_DISCARD:
+ DRM_DEBUG(RADEON_CMD_DMA_DISCARD\n);
+idx = header.dma.buf_idx;
+if (idx 0 || idx = dma-buf_count) {
+DRM_ERROR(buffer index %d (of %d max)\n,
+ idx, dma-buf_count - 1);
+return DRM_ERR(EINVAL);
+}
+
+buf = dma-buflist[idx];
+if (buf-filp != filp || buf-pending) {
+DRM_ERROR(bad buffer %p %p %d\n,
+ buf-filp, filp, buf-pending);
+return DRM_ERR(EINVAL);
+}
+
+r300_discard_buffer(dev, buf);
+break;
+
default:
DRM_ERROR(bad cmd_type %i at %p\n,
header.header.cmd_type,
diff -Nur r300_driver/drm/shared-core/radeon_drm.h
r300_driver_wip/drm/shared-core/radeon_drm.h
--- r300_driver/drm/shared-core/radeon_drm.h2005-01-02 05:32:52.0
+1100
+++ r300_driver_wip/drm/shared-core/radeon_drm.h2005-02-06
20:20:06.0 +1100
@@ -199,6 +199,7 @@
#define R300_CMD_PACKET3 3 /* emit a packet3 */
#define R300_CMD_END3D 4 /* emit sequence ending 3d rendering
*/
#define R300_CMD_CP_DELAY 5
+#define R300_CMD_DMA_DISCARD 6
typedef union {
unsigned int u;
@@ -218,6 +219,9 @@
unsigned char cmd_type, packet;
unsigned short count; /* amount of packet2 to emit */
} delay;
+ struct {
+ unsigned char cmd_type, buf_idx, pad0, pad1;
+ } dma;
} drm_r300_cmd_header_t;
#define RADEON_FRONT 0x1
diff -Nur r300_driver/drm/shared-core/radeon_drv.h
r300_driver_wip/drm/shared-core/radeon_drv.h
--- r300_driver/drm/shared-core/radeon_drv.h2004-12-28 07:44:39.0
+1100
+++ r300_driver_wip/drm/shared-core/radeon_drv.h2005-02-11
05:11:02.953087192 +1100
@@ -310,6 +310,7 @@
/* r300_cmdbuf.c */
extern int r300_do_cp_cmdbuf( drm_device_t* dev,
+ DRMFILE filp,
drm_file_t* filp_priv,
drm_radeon_cmd_buffer_t* cmdbuf );
diff -Nur r300_driver/drm/shared-core/radeon_state.c
r300_driver_wip/drm/shared-core/radeon_state.c
--- r300_driver/drm/shared-core/radeon_state.c 2005-01-31 13:33:24.0
+1100
+++ r300_driver_wip/drm/shared-core/radeon_state.c 2005-02-06
20:20:06.0 +1100
@@ -2469,7 +2469,7 @@
return DRM_ERR(EFAULT);
if ( IS_FAMILY_R300(dev_priv) )
- return r300_do_cp_cmdbuf(dev, filp_priv
Re: DRM change for R300 DMA
Michel 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? AFAIK they aren't, the only data the radeon and r200 drivers upload to the framebuffer is textures. I didn't think that they were, at least, I couldn't see where it was done and thought I was misunderstanding something. Thankyou for clearing that up. Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
Hello Jan, The patch to the drm shouldn't have actually done anything on it's own. It requires that r300_ioctl be modified to be of any use at all. I'll have a look into it some more in the morning. Ben Skeggs. Jan Kreuzer wrote: Hi Ben your patch seems to solve some of the lockups I experienced (for example without your patch i got random lockups after trying some of the nehe lessons, now i can run most of them fine). However i noticed that xorg cpu-usage went up to 10% (from around 1%) and that the screen rendering (2D and 3D) stops a short time every second. Also nehe-lesson-16 still produces a hardlock. I will test more with neverball and tuxracer (as i am in x86_64 i could not test 32-bit legacy apps). Greetings Jan --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
Hello Vladimir,
1) It does not appear to be R300 specific - why doesn't similar
Radeon ioctl work ? Also, I would imagine that this would
require a change in r300 driver to work, wouldn't it ?
No, I suspected that it wasn't r300 specific actually, all the code does is
write to a scratch register. So perhaps I should've just hooked up
a R300_* ioctl number to the radeon code.
2) I was able to play Quake for somewhat prolonged periods,
I don't think this would have really worked if aging was
truly broken, though, maybe, I am wrong on this one.
Would you have a test app that shows brokenness ? Perhaps
something that uses a lot of textures once.
It only seems to occur after the reference counts for all the dma
buffers hit
zero. After that, no more r300AllocDmaRegion calls are successful.
The code I was referring to was r300_dri hacked up to use r300AllocDmaRegion
to grab buffers for vertex data, rather than using rsp-gartTextures.map to
store the data. It was just a little experiment I was trying, I've
attached a diff
so you can see what happens for yourself, I may have missed something
important.
In r300ReleaseDmaRegion there is a #if/#endif to either use the ioctl or
not.
One more thing, I'm not sure how to find the gart offset of the
vertex/indirect
buffers, I've been hardcoding the value for now (r300_ioctl.h::GET_START),
you may need to look in your X log for the handle as it might differ
from mine.
glxgears looks a little broken using this aswell, I have some random
colours across the faces of the gears.
Anyhow, it was a little experiment I was doing to see how to implement
vertex buffers.
Ben Skeggs.
diff -Nur orig/r300_context.h mod/r300_context.h
--- orig/r300_context.h 2005-02-04 04:48:32.0 +1100
+++ mod/r300_context.h 2005-02-05 04:08:09.0 +1100
@@ -96,7 +96,11 @@
drmBufPtr buf;
};
-#define GET_START(rvb) (rmesa-radeon.radeonScreen-gart_buffer_offset +
\
+//#define GET_START(rvb) (rmesa-radeon.radeonScreen-gart_buffer_offset +
\
+ (rvb)-address - rmesa-dma.buf0_address + \
+ (rvb)-start)
+
+#define GET_START(rvb) (0xe0102000 + \
(rvb)-address - rmesa-dma.buf0_address + \
(rvb)-start)
diff -Nur orig/r300_ioctl.c mod/r300_ioctl.c
--- orig/r300_ioctl.c 2005-02-02 02:46:23.0 +1100
+++ mod/r300_ioctl.c2005-02-08 03:02:21.0 +1100
@@ -414,7 +414,7 @@
if (rmesa-dma.flush)
rmesa-dma.flush(rmesa);
-
+#if 1
if (--region-buf-refcount == 0) {
drm_radeon_cmd_header_t *cmd;
@@ -424,13 +424,15 @@
cmd =
(drm_radeon_cmd_header_t *) r300AllocCmdBuf(rmesa,
- sizeof(*cmd),
+ sizeof(*cmd) /
4,
__FUNCTION__);
- cmd-dma.cmd_type = RADEON_CMD_DMA_DISCARD;
+ cmd-dma.cmd_type = R300_CMD_DMA_DISCARD;
cmd-dma.buf_idx = region-buf-buf-idx;
FREE(region-buf);
+
rmesa-dma.nr_released_bufs++;
}
+#endif
region-buf = 0;
region-start = 0;
diff -Nur orig/r300_render.c mod/r300_render.c
--- orig/r300_render.c 2005-02-04 06:51:57.0 +1100
+++ mod/r300_render.c 2005-02-08 03:10:41.149064384 +1100
@@ -381,6 +381,8 @@
/* vertex buffer implementation */
/* We use the start part of GART texture buffer for vertices */
+ static struct r300_dma_region rvb[8];
+ static int nr_rvb = 0;
static void upload_vertex_buffer(r300ContextPtr rmesa, GLcontext *ctx)
@@ -394,33 +396,38 @@
/* A hack - we don't want to overwrite vertex buffers, so we
just use AGP space for them.. Fix me ! */
+#if 0
static int offset=0;
if(offset2*1024*1024){
//fprintf(stderr, Wrapping agp vertex buffer offset\n);
offset=0;
}
+#endif
+
/* Not the most efficient implementation, but, for now, I just want
something that
works */
/* to do - make single memcpy per column (is it possible ?) */
/* to do - use dirty flags to avoid redundant copies */
#define UPLOAD_VECTOR(v)\
{ \
+ r300AllocDmaRegion(rmesa, rvb[nr_rvb], v-stride*VB-Count,
4); \
/* Is the data dirty ? */ \
if (v-flags ((1v-size)-1)) { \
/* fprintf(stderr, size=%d vs stride=%d\n, v-size,
v-stride); */ \
if(v-size*4==v-stride){\
/* fast path */ \
- memcpy(rsp-gartTextures.map+offset, v-data,
v-stride*VB-Count
Re: DRM change for R300 DMA
The thing we can (and do) use radeon ioctls from within the driver. So we can just call the Radeon ioctls directly - no need for R300 version. This did bite us in the past, and ,probably, still does because of the need for different engine idle sequence for R300. Ah, I did not realise that we could (and do) just call the radeon ioctls. AFAIK, r300AllocDMA region allocates one of a several predefined buffers (you can see them printed by r300_demo), so if you do not free them there is nothing more to allocate. They do get freed at the end of r300_run_vb_render. r300ReleaseDmaRegion is the function which calls the ioctl. I could be completely off on this one though - I can't look at the actual code at the moment and might have confused functions. With regard to vertex buffers - these are in framebuffer memory, not in AGP one on R200 hardware (at least this was my understanding). r200EmitArrays (which does much that same as upload_vertex_buffer in r300_dri) uses the alloc/release dma calls to grab the regions. Could someone with knowledge of r200_dri explain how vertex buffer uploads are put into framebuffer memory on r200? I had just assumed that the driver told r200 of the address of the buffer acquired from AllocDma. I've mostly likely got something very confused here. Thanks, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM change for R300 DMA
Hello Vladimir,
I've attached a patch which implements the RADOEN_CMD_DMA_DISCARD ioctl from
the radeon/r200 drm. I thought I'd post here before commiting to cvs in
case I've
done something bad.
Without this, eventually r300AllocDmaRegion will get stuck in a loop
continually calling
drmDMA (r300_ioctl.c::r300RefillCurrentDmaRegion).
It seems that the drm buffer management code depends on having a scratch
register
containing the age of a buffer. I'm not sure of the details, I just
know that it stops
the infinite drmDMA loop.
Is this the correct way of fixing this? Or have I completely missed
something?
Regards,
Ben Skeggs.
diff -Nur drm.old/shared-core/r300_cmdbuf.c drm/shared-core/r300_cmdbuf.c
--- drm.old/shared-core/r300_cmdbuf.c 2005-01-08 13:46:34.0 +1100
+++ drm/shared-core/r300_cmdbuf.c 2005-02-06 20:20:06.910617312 +1100
@@ -354,16 +354,37 @@
return 0;
}
+static void r300_discard_buffer(drm_device_t * dev, drm_buf_t * buf)
+{
+drm_radeon_private_t *dev_priv = dev-dev_private;
+drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
+RING_LOCALS;
+
+buf_priv-age = ++dev_priv-sarea_priv-last_dispatch;
+
+/* Emit the vertex buffer age */
+BEGIN_RING(2);
+RADEON_DISPATCH_AGE(buf_priv-age);
+ADVANCE_RING();
+
+buf-pending = 1;
+buf-used = 0;
+}
+
+
/**
* Parses and validates a user-supplied command buffer and emits appropriate
* commands on the DMA ring buffer.
* Called by the ioctl handler function radeon_cp_cmdbuf.
*/
int r300_do_cp_cmdbuf(drm_device_t* dev,
+ DRMFILE filp,
drm_file_t* filp_priv,
drm_radeon_cmd_buffer_t* cmdbuf)
{
drm_radeon_private_t *dev_priv = dev-dev_private;
+drm_device_dma_t *dma = dev-dma;
+drm_buf_t *buf = NULL;
int ret;
DRM_DEBUG(\n);
@@ -375,6 +396,7 @@
}
while(cmdbuf-bufsz = sizeof(drm_r300_cmd_header_t)) {
+ int idx;
drm_r300_cmd_header_t header;
if (DRM_GET_USER_UNCHECKED(header.u, (int __user*)cmdbuf-buf))
{
@@ -431,6 +453,26 @@
ADVANCE_RING();
}
return 0;
+
+ case R300_CMD_DMA_DISCARD:
+ DRM_DEBUG(RADEON_CMD_DMA_DISCARD\n);
+idx = header.dma.buf_idx;
+if (idx 0 || idx = dma-buf_count) {
+DRM_ERROR(buffer index %d (of %d max)\n,
+ idx, dma-buf_count - 1);
+return DRM_ERR(EINVAL);
+}
+
+buf = dma-buflist[idx];
+if (buf-filp != filp || buf-pending) {
+DRM_ERROR(bad buffer %p %p %d\n,
+ buf-filp, filp, buf-pending);
+return DRM_ERR(EINVAL);
+}
+
+r300_discard_buffer(dev, buf);
+break;
+
default:
DRM_ERROR(bad cmd_type %i at %p\n,
header.header.cmd_type,
diff -Nur drm.old/shared-core/radeon_drm.h drm/shared-core/radeon_drm.h
--- drm.old/shared-core/radeon_drm.h2005-01-02 05:32:52.0 +1100
+++ drm/shared-core/radeon_drm.h2005-02-06 20:20:06.910617312 +1100
@@ -199,6 +199,7 @@
#define R300_CMD_PACKET3 3 /* emit a packet3 */
#define R300_CMD_END3D 4 /* emit sequence ending 3d rendering
*/
#define R300_CMD_CP_DELAY 5
+#define R300_CMD_DMA_DISCARD 6
typedef union {
unsigned int u;
@@ -218,6 +219,9 @@
unsigned char cmd_type, packet;
unsigned short count; /* amount of packet2 to emit */
} delay;
+ struct {
+ unsigned char cmd_type, buf_idx, pad0, pad1;
+ } dma;
} drm_r300_cmd_header_t;
#define RADEON_FRONT 0x1
diff -Nur drm.old/shared-core/radeon_drv.h drm/shared-core/radeon_drv.h
--- drm.old/shared-core/radeon_drv.h2004-12-28 07:44:39.0 +1100
+++ drm/shared-core/radeon_drv.h2005-02-06 20:20:06.910617312 +1100
@@ -310,6 +310,7 @@
/* r300_cmdbuf.c */
extern int r300_do_cp_cmdbuf( drm_device_t* dev,
+ DRMFILE filp,
drm_file_t* filp_priv,
drm_radeon_cmd_buffer_t* cmdbuf );
diff -Nur drm.old/shared-core/radeon_state.c drm/shared-core/radeon_state.c
--- drm.old/shared-core/radeon_state.c 2005-01-31 13:33:24.0 +1100
+++ drm/shared-core/radeon_state.c 2005-02-06 20:20:06.909617464 +1100
@@ -2469,7 +2469,7 @@
return DRM_ERR(EFAULT);
if ( IS_FAMILY_R300(dev_priv) )
- return r300_do_cp_cmdbuf(dev, filp_priv, cmdbuf);
+ return r300_do_cp_cmdbuf(dev, filp, filp_priv, cmdbuf);
else
return radeon_do_cp_cmdbuf(dev, filp, filp_priv, cmdbuf);
}
Re: [R300] jump_and_click snapshot
Hello, The big change is that q3demo should now play in game mode, albeit with some texture related artifacts which are due to missing pixel shader generator. Thanks to Rune Petersen for nailing down the cause of lockups in NeHe lesson 20 ! lesson20 now works correctly without lockups for me. I'm unable to enter a game in quake3 (retail 1.32b) though. I don't have a lockup, but just after the intro screen, quake3 exits, with this message: quake3.x86: r300_cmdbuf.h:56: r300EnsureCmdBufSpace: Assertion `dwords r300-cmdbuf.size' failed. * rewrite r300_render.c to use proper mesa code (templates?) and support vertex buffers. I've started some preliminary work on porting the r200 maos code over. Is this a good starting point for implementing vertex buffers? I still don't understand a fair bit of the driver, but I'm having fun messing with it in my (somewhat limited) spare time. Thanks for the update Vladimir, and to everyone who's contributed. Ben Skeggs. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click snapshot
lesson20 now works correctly without lockups for me. I'm unable to enter a game in quake3 (retail 1.32b) though. I don't have a lockup, but just after the intro screen, quake3 exits, with this message: quake3.x86: r300_cmdbuf.h:56: r300EnsureCmdBufSpace: Assertion `dwords r300-cmdbuf.size' failed. This should not really happen could you try to track down what causes it ? It might worthwhile to try turning off/on different graphics features in quake. I've tracked the problem down to using compiled vertex arrays (r_ext_compiled_vertex_array in q3config.cfg). Is this something we should be able to handle? Or is there a fallback we should be catching somewhere? Anyhow, quake3 runs now. At the very least it is a good starting point to look at :) The current scheme is closer to maos code, though it would be nicer (and cleaner) if there were one of the templates that other drivers use. Is there any documentation on the use of these templates? Regards, Ben Skeggs. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] noisy_cube snapshot
Peter Zubaj wrote: glxgeas and lesson06 works ok - no more lockups here. This is big improvement :-) x11perf still locks (and x server crash sometimes) even without using 3D. Where can be problem ??? When the xserver crashes, do you see WaitForSomething(): select: errno=22 on the console? I get this error sometimes, and programs randomly die. There's a bug report on the freedesktop bugzilla, but no resolution yet. IIRC it has something to do with the new DRM. Ben Skeggs. Peter Zubaj http://www.logofun.pobox.sk - urobte radost svojmu telefonu --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] noisy_cube snapshot
Also, I seem to have lost the ability to trigger lockups with x11perf. Strange, as it used to be I can do it repeatedly after a clean boot.. I cannot cause the x11perf lockups anymore either. Could you try to do this: In X.org 2d driver, find file radeon_dri.c, function RADEONEnterServer and try disabling the R300 piece with the long comment. I am curious to know whether a) You still see lockups with this disabled When the code is commented out glxgears locks up after a second or two for me. Ben Skeggs --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] rotating_gears snapshot
The gears seem to look normal now.
Without drm debugging I was able to resize the glxgears window without
lockups, but only while the r300_dri debug output wasn't redirected.
With glxgears 2/dev/null, resizing the window caused a lockup.
The interesting thing is that the artifacts still appear outside of the
glxgears window. Is anyone else testing with an RV350 that can confirm
this? Perhaps there's a small difference to the R300.
Ben Skeggs.
Vladimir Dergachev wrote:
Cool, could you try the new version of rotating_gears ?
I am curious to see whether it works any better for you.
thank you
Vladimir Dergachev
On Fri, 31 Dec 2004, Peter Zubaj wrote:
r300_demo runs with or without this code (and without code in
radeon_state.c too)
One more thing: try this code instead:
if (IS_FAMILY_R300(dev_priv)) {
BEGIN_RING( 6 );
OUT_RING_REG(R300_RB3D_DSTCACHE_CTLSTAT, 0x0002);
OUT_RING_REG(0x4F18, 0x0001); /* Z cache? */
/* It seems a delay is needed */
OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) );
OUT_RING( 0x0 );
ADVANCE_RING();
}
With this code I was able run glxgears on full screen (with glxgears
2/dev/null - produced lock). Maybe I have only luck :-)
Peter Zubaj
RAMMSTEIN, 22.02.2005 o 20,00, Bratislava Incheba, Info: 0904 666 363,
http://www.xl.sk
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] rotating_gears snapshot
Hello, Well, this has progressed nicely since last time I checked in on it. Well done. I've tested the latest CVS on RV350 AP(0x4150) and it works without lockups. Although, while glxgears is running I seem to have artifacts around the rest of my screen. Also, vertex_shader.h and pixel_shader.h seem to be missing from the r300_driver module, I needed to copy them over from r300_demo. Good work! Ben Skeggs. Vladimir Dergachev wrote: Hi all, New snapshot of r300_driver is available. Get it from CVS, tag rotating_gears Changes: * code cleanup, do not clobber hardware state as much as before * hook up projection matrix - displays actually rotating gears * vertex buffer mode (not used by defaul) Problems: * I don't seem to get gears to display properly in vertex buffer mode, probably having problems synchronizing vertex buffers to command stream * the gears don't display quite right, although there was a single (apparently random) occurence of proper picture. Looks like a problem with culling and/or depth buffer settings. Enjoy ! Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] rotating_gears snapshot
Cool ! Can you resize the window without lockups as well ? No, I can't. I didn't think to test that until after my last email. This is very interesting - I see no artifacts on my computer. Could you tell what resolution/colordepth are you running at ? How much memory does your card have ? Perhaps artifacts is the wrong word to use. But it seemed that parts of the gears were being rendered outside of the glxgears window, just short horizontal lines in the colours of the gears. Anyway, I was running in 1400x1050 24-bit, my card has 256MB of memory. I'd been meaning to study the DRI architecture a fair while ago, in hopes that I'd be able to contribute, but never got around to it. I'm starting to get a general idea of how things fit together with Mesa now. Watching this driver come together has been the perfect opportunity to learn! Regards, Ben Skeggs. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] rotating_gears snapshot
Cool ! Can you resize the window without lockups as well ? No, I can't. I didn't think to test that until after my last email. Okay, that wasn't quite true. I was just attempting to get the drm log of what happened on the lockup and it was quite hard to produce with drm debugging on. I'm guessing there's some kind of synchronisation problem which doesn't show up as easily when the system is busy doing something else. I believe this is the part of my log related to the lockup. The cp_idle's continue until I reboot. Dec 31 03:52:34 disoft-dc [drm:r300_do_cp_cmdbuf] R300_CMD_UNCHECKED_STATE Dec 31 03:52:34 disoft-dc [drm:r300_do_cp_cmdbuf] R300_CMD_UNCHECKED_STATE Dec 31 03:52:34 disoft-dc [drm:r300_do_cp_cmdbuf] R300_CMD_UNCHECKED_STATE Dec 31 03:52:34 disoft-dc [drm:r300_do_cp_cmdbuf] R300_CMD_UNCHECKED_STATE Dec 31 03:52:34 disoft-dc [drm:r300_emit_packet3] R300_CMD_PACKET3_RAW Dec 31 03:52:34 disoft-dc [drm:r300_do_cp_cmdbuf] R300_CMD_UNCHECKED_STATE Dec 31 03:52:34 disoft-dc [drm:r300_do_cp_cmdbuf] END Dec 31 03:52:34 disoft-dc [drm:drm_ioctl] pid=5554, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 Dec 31 03:52:34 disoft-dc [drm:drm_lock] 1 (pid 5554) requests lock (0x8003), flags = 0x Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] pid=5606, cmd=0x4008642b, nr=0x2b, dev 0xe200, auth=1 Dec 31 03:52:35 disoft-dc [drm:drm_lock] 1 has lock Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] pid=5554, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 Dec 31 03:52:35 disoft-dc [drm:radeon_cp_idle] Dec 31 03:52:35 disoft-dc [drm:radeon_do_cp_idle] Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] ret = fff0 Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] pid=5554, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 Dec 31 03:52:35 disoft-dc [drm:radeon_cp_idle] Dec 31 03:52:35 disoft-dc [drm:radeon_do_cp_idle] Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] ret = fff0 Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] pid=5554, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 Dec 31 03:52:35 disoft-dc [drm:radeon_cp_idle] Dec 31 03:52:35 disoft-dc [drm:radeon_do_cp_idle] Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] ret = fff0 Dec 31 03:52:35 disoft-dc [drm:drm_ioctl] pid=5554, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: r300 Report.]
Hello, The PCI ID is already added in the DRM branch of r300_driver. As for the AGP issues, I have no idea. Maybe they're related to the lockup, maybe not. cu, Nicolai I think the AGP issues *are* related to the lockup. I've just switched sysloggers, and switched to CVS XServer (was using release 6.8 before). My previous problems still occurred, but I now seem to have a lot more debugging information in my syslog. I have the same AGP problem. If I set AGP to 4x in my BIOS (rather than 8x), the corruption, and the lockup don't occur. I've attached my syslog from when the lockup occurred, in case it helps. I also have the problem as Pat, where glxinfo reports direct rendering: No, but my Xorg log says it is. Ben Skeggs Nov 7 07:37:41 disoft-dc [drm:drm_core_init] drm_agp c0459e00 Nov 7 07:37:41 disoft-dc [drm] Initialized drm 1.0.0 20040925 Nov 7 07:37:44 disoft-dc [drm:drm_init] Nov 7 07:37:44 disoft-dc [drm:drm_get_dev] Nov 7 07:37:44 disoft-dc ACPI: PCI interrupt :02:00.0[A] - GSI 19 (level, high) - IRQ 19 Nov 7 07:37:44 disoft-dc [drm:drm_initmap] Nov 7 07:37:44 disoft-dc [drm:drm_initmap] initmap offset = 0xe900, size = 0x0001, type = 1 Nov 7 07:37:44 disoft-dc [drm:drm_initmap] finished Nov 7 07:37:44 disoft-dc [drm:drm_initmap] Nov 7 07:37:44 disoft-dc [drm:drm_initmap] initmap offset = 0xc000, size = 0x1000, type = 0 Nov 7 07:37:44 disoft-dc [drm:drm_initmap] finished Nov 7 07:37:44 disoft-dc [drm:radeon_preinit] AGP card detected Nov 7 07:37:45 disoft-dc [drm:setup_i2c_bus] I2C bus monid registered. Nov 7 07:37:45 disoft-dc [drm:setup_i2c_bus] I2C bus dvi registered. Nov 7 07:37:45 disoft-dc [drm:setup_i2c_bus] I2C bus vga registered. Nov 7 07:37:47 disoft-dc [drm:setup_i2c_bus] I2C bus crt2 registered. Nov 7 07:37:47 disoft-dc [drm:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0 Nov 7 07:37:47 disoft-dc [drm:drm_ctxbitmap_init] drm_ctxbitmap_init : 0 Nov 7 07:37:47 disoft-dc [drm:drm_get_head] Nov 7 07:37:47 disoft-dc [drm:drm_get_head] new minor assigned 0 Nov 7 07:37:47 disoft-dc [drm] Initialized radeon 1.12.0 20041023 on minor 0: ATI Technologies Inc RV350 AP [Radeon 9600] Nov 7 07:37:58 disoft-dc [drm:drm_stub_open] Nov 7 07:37:58 disoft-dc [drm:drm_open_helper] pid = 15162, minor = 0 Nov 7 07:37:58 disoft-dc [drm:drm_setup] Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_release] open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_release] pid = 15162, device = 0xe200, open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_fasync] fd = -1, device = 0xe200 Nov 7 07:37:58 disoft-dc [drm:drm_takedown] Nov 7 07:37:58 disoft-dc [drm:radeon_do_cleanup_cp] Nov 7 07:37:58 disoft-dc [drm:drm_stub_open] Nov 7 07:37:58 disoft-dc [drm:drm_open_helper] pid = 15162, minor = 0 Nov 7 07:37:58 disoft-dc [drm:drm_setup] Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_release] open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_release] pid = 15162, device = 0xe200, open_count = 1 Nov 7 07:37:58 disoft-dc [drm:drm_fasync] fd = -1, device = 0xe200 Nov 7 07:37:58 disoft-dc [drm:drm_takedown] Nov 7 07:37:58 disoft-dc [drm:radeon_do_cleanup_cp] Nov 7 07:37:58 disoft-dc [drm:drm_stub_open] Nov 7 07:37:58 disoft-dc [drm:drm_open_helper] pid = 15162, minor = 0 Nov 7 07:37:58 disoft-dc [drm:drm_setup] Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] offset = 0x, size = 0x2000, type = 2 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] 8192 13 e0911000 Nov 7 07:37:58 disoft-dc [drm:drm_mmap] start = 0xafcf4000, end = 0xafcf6000, offset = 0xe0911000 Nov 7 07:37:58 disoft-dc [drm:drm_vm_open] 0xafcf4000,0x2000 Nov 7 07:37:58 disoft-dc [drm:drm_do_vm_shm_nopage] shm_nopage 0xafcf4000 Nov 7 07:37:58 disoft-dc [drm:drm_do_vm_shm_nopage] shm_nopage 0xafcf5000 Nov 7 07:37:58 disoft-dc [drm:drm_ioctl] pid=15162, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] offset = 0xc000, size = 0x0800, type = 0 Nov 7 07:37:58 disoft-dc [drm:drm_addmap] Looking for: offset = 0xc000, size = 0x0800, type = 0 Nov 7 07:37:58 disoft-dc [drm:drm_addmap
Re: [Fwd: r300 Report.]
As long as the X server works and uses the ring buffer, that would point towards a simple configuration problem. Perhaps you could post a log of glxinfo with LIBGL_DEBUG=all and RADEON_DEBUG=all? cu, Nicolai Hmm, I believe you may be right about the config problem, I'm not sure why I didn't think of running glxinfo with LIBGL_DEBUG=all before.. [EMAIL PROTECTED] ~ $ LIBGL_DEBUG=all glxinfo name of display: :0.0 libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed (/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol: XML_SetElementHandler) libGL error: unable to find driver: r300_dri.so --snip-- I'll have a mess around and try to find out what's going on there. Ben. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: r300 Report.]
r300_dri.so needs to get linked against expat. - ajax Yup, that did the trick. Thankyou. Any thoughts as to why it wasn't linked against expat when I built it the first time around? Ben. from glxinfo: disabling 3D acceleration name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R300 20040924 AGP 1x x86/MMX+/3DNow!+/SSE NO-TCL OpenGL version string: 1.3 Mesa 6.3 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL
r300.sf.net lockup
Hello, I've been trying to get the experimental r300.sf.net driver to work on my machine. I've compiled and installed it ok, but everytime I start the X server with DRI enabled, the top of the screen is corrupted, which I'm assuming is the xterms that are supposed to be showing. However, the mouse pointer is draw correctly, and I'm still able to move it. I've posted what I captured in syslog, and my xorg log below. The card is a Powercolor Radeon 9600 256MB (RV350 AP), I tested with vanilla 2.6.9 with reiser4 patched in. :02:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] (prog-if 00 [VGA]) Subsystem: C.P. Technology Co. Ltd PowerColor R96A-C3N Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 19 Memory at c000 (32-bit, prefetchable) I/O ports at c000 [size=256] Memory at e900 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 :02:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary) Subsystem: C.P. Technology Co. Ltd: Unknown device 2065 Flags: 66Mhz, medium devsel Memory at d000 (32-bit, prefetchable) [disabled] Memory at e901 (32-bit, non-prefetchable) [disabled] [size=64K] Capabilities: [50] Power Management version 2 **Xorg.0.log X Window System Version 6.8.0 Release Date: 8 September 2004 X Protocol Version 11, Revision 0, Release 6.8 Build Operating System: Linux 2.6.9-nitro2 i686 [ELF] Current Operating System: Linux disoft-dc 2.6.9 #3 Thu Nov 4 17:19:18 EST 2004 i686 Build Date: 04 November 2004 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Nov 6 06:01:08 2004 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Server Layout (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device radeon (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) FontPath set to unix/:-1 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6/lib/modules (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=X.Org Foundation compiled for 6.8.0, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=X.Org Foundation compiled for 6.8.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 Using vt 7 (--) using VT number 7 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x80020060, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 10de,01e0 card 147b,1c00 rev c1 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 10de,01eb card 10de,0c17 rev c1 class 05,00,00 hdr 80 (II) PCI: 00:00:2: chip 10de,01ee card 10de,0c17 rev c1 class 05,00,00 hdr 80 (II) PCI: 00:00:3: chip 10de,01ed card 10de,0c17 rev c1 class 05,00,00 hdr 80 (II) PCI: 00:00:4: chip 10de,01ec card 10de,0c17 rev c1 class 05,00,00 hdr 80 (II) PCI: 00:00:5: chip 10de,01ef card 10de,0c17 rev c1 class 05,00,00 hdr 80 (II) PCI: 00:01:0: chip 10de,0060 card 147b,1c00 rev a4 class 06,01,00 hdr 80 (II) PCI: 00:01:1: chip 10de,0064 card 147b,1c00 rev a2 class 0c,05,00 hdr 80 (II) PCI: 00:02:0: chip 10de,0067 card 147b,1c00 rev a4 class 0c,03,10 hdr 80 (II) PCI: 00:02:1: chip 10de,0067 card 147b,1c00 rev a4 class 0c,03,10 hdr 80 (II) PCI: 00:02:2: chip 10de,0068 card 147b,1c00 rev a4 class 0c,03,20 hdr 80 (II) PCI: 00:04:0: chip 10de,0066 card 147b,1c00 rev a1 class 02,00,00 hdr 00 (II) PCI: 00:05:0: chip 10de,006b card 147b,1c00 rev a2 class 04,01,00 hdr 00 (II) PCI: 00:06:0: chip 10de,006a card 147b,1c00 rev a1 class 04,01,00 hdr 00 (II) PCI: 00:08:0: chip 10de,006c card , rev a3 class 06,04,00 hdr 01 (II) PCI: 00:09:0: chip 10de,0065 card 147b,1c00 rev a2 class 01,01,8a hdr 00 (II) PCI: 00:0d:0: chip 10de,006e card 147b,1c00 rev a3 class 0c,00,10 hdr 00 (II) PCI: 00:1e:0: chip 10de,01e8 card , rev c1 class 06,04,00 hdr 01 (II) PCI: 01:07:0: chip 10ec,8139 card 10bd,0320 rev 10 class 02,00,00 hdr 00 (II) PCI: 01:0b:0: chip 1095,3112 card 1095,6112 rev 02 class 01,04,00 hdr 00 (II) PCI: 02:00:0: chip 1002,4150 card
