[Bug 2062] backbuffer scissored glClear misplaced
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2062 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 00:32 --- Yes, the viaBlit unification in via_ioctl.c solved this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2066] Polygons with parts outside the window gets misrendered.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2066 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 04:35 --- the problem occurs somewhere in CopyPV called from via_vb_cliptmp.h, still investigating -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1707] r200 Radeon driver and Wings 3D
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1707 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Radeon driver and Wings 3D |r200 Radeon driver and Wings ||3D --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 09:38 --- Take a look at http://homepages.vype.de/egore/r200-dri.png for how it looks on an r200 and at http://homepages.vype.de/egore/r300-nodri.png for how it looks like on an r300. I hope these examples are quite helpful. The second image shows how it should look like (especially look at the green lines), bit the first one shows typical z-buffer I-don't-know-what's-in-front problems. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Looking for some answers.
Hi. Is MergedFB going to replace xinerama in the long run? if not, will xinerama be able to use 3D / Xv properly on radeon (9000) in the near future? why doesnt radeon xinerama use mergedFB techniques to acieve its ends ? --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 2.6.10-rc3 1/4] agpgart: allow multiple backends to be initialized
This new version reduces the number of changes required by users of the agpgart
such as drm to support the new api for multiple agp bridges.
The first patch doesn't touch any platform specific files and all current
platform
gart drivers will just work the same as they do now since the global
agp_bridge is still supported as the default bridge.
Summary for the 4 patches.
[1/4] Allow multiple backends to be initialized for agpgart
[2/4] Run Lindent on generic.c
[3/4] Patch drm code to work with modified agpgart api.
[4/4] Patch framebuffer code to work with modified agpgart api.
-
drivers/char/agp/agp.h |3 +
drivers/char/agp/backend.c | 112 +---
drivers/char/agp/frontend.c | 30 ++-
drivers/char/agp/generic.c | 71 ---
include/linux/agp_backend.h | 32 +++-
5 files changed, 145 insertions(+), 103 deletions(-)
# This is a BitKeeper generated diff -Nru style patch.
#
# Allow multiple backends to be initialized
#
diff -Nru a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
--- a/drivers/char/agp/agp.h2004-12-17 10:36:04 -08:00
+++ b/drivers/char/agp/agp.h2004-12-17 10:36:04 -08:00
@@ -1,5 +1,6 @@
/*
* AGPGART
+ * Copyright (C) 2004 Silicon Graphics, Inc.
* Copyright (C) 2002-2004 Dave Jones
* Copyright (C) 1999 Jeff Hartmann
* Copyright (C) 1999 Precision Insight, Inc.
@@ -139,6 +140,7 @@
int capndx;
char major_version;
char minor_version;
+ struct list_head list;
};
#define OUTREG64(mmap, addr, val) __raw_writeq((val), (mmap)+(addr))
@@ -271,6 +273,7 @@
void global_cache_flush(void);
void get_agp_version(struct agp_bridge_data *bridge);
unsigned long agp_generic_mask_memory(unsigned long addr, int type);
+struct agp_bridge_data *agp_generic_find_bridge(struct pci_dev *pdev);
/* generic routines for agp=3 */
int agp3_generic_fetch_size(void);
diff -Nru a/drivers/char/agp/backend.c b/drivers/char/agp/backend.c
--- a/drivers/char/agp/backend.c2004-12-17 10:36:04 -08:00
+++ b/drivers/char/agp/backend.c2004-12-17 10:36:04 -08:00
@@ -1,5 +1,6 @@
/*
* AGPGART driver backend routines.
+ * Copyright (C) 2004 Silicon Graphics, Inc.
* Copyright (C) 2002-2003 Dave Jones.
* Copyright (C) 1999 Jeff Hartmann.
* Copyright (C) 1999 Precision Insight, Inc.
@@ -42,34 +43,36 @@
* fix some real stupidity. It's only by chance we can bump
* past 0.99 at all due to some boolean logic error. */
#define AGPGART_VERSION_MAJOR 0
-#define AGPGART_VERSION_MINOR 100
+#define AGPGART_VERSION_MINOR 101
static struct agp_version agp_current_version =
{
.major = AGPGART_VERSION_MAJOR,
.minor = AGPGART_VERSION_MINOR,
};
-static int agp_count=0;
-
-struct agp_bridge_data agp_bridge_dummy = { .type = NOT_SUPPORTED };
-struct agp_bridge_data *agp_bridge = agp_bridge_dummy;
+struct agp_bridge_data *agp_bridge;
+LIST_HEAD(agp_bridges);
+struct agp_bridge_data *(*agp_find_bridge)(struct pci_dev *pdev);
EXPORT_SYMBOL(agp_bridge);
-
+EXPORT_SYMBOL(agp_bridges);
/**
- * agp_backend_acquire - attempt to acquire the agp backend.
+ * agp_backend_acquire - attempt to acquire an agp backend.
*
- * returns -EBUSY if agp is in use,
- * returns 0 if the caller owns the agp backend
*/
-int agp_backend_acquire(void)
+struct agp_bridge_data *agp_backend_acquire(struct pci_dev *pdev)
{
- if (agp_bridge-type == NOT_SUPPORTED)
- return -EINVAL;
- if (atomic_read(agp_bridge-agp_in_use))
- return -EBUSY;
- atomic_inc(agp_bridge-agp_in_use);
- return 0;
+ struct agp_bridge_data *bridge;
+
+ bridge = agp_find_bridge(pdev);
+
+ if (!bridge)
+ return NULL;
+
+ if (atomic_read(bridge-agp_in_use))
+ return NULL;
+ atomic_inc(bridge-agp_in_use);
+ return bridge;
}
EXPORT_SYMBOL(agp_backend_acquire);
@@ -82,10 +85,11 @@
*
* (Ensure that all memory it bound is unbound.)
*/
-void agp_backend_release(void)
+void agp_backend_release(struct agp_bridge_data *bridge)
{
- if (agp_bridge-type != NOT_SUPPORTED)
- atomic_dec(agp_bridge-agp_in_use);
+
+ if (bridge)
+ atomic_dec(bridge-agp_in_use);
}
EXPORT_SYMBOL(agp_backend_release);
@@ -121,7 +125,6 @@
(maxes_table[index].agp - maxes_table[index - 1].agp)) /
(maxes_table[index].mem - maxes_table[index - 1].mem);
- printk(KERN_INFO PFX Maximum main memory to use for agp memory:
%ldM\n, result);
result = result (20 - PAGE_SHIFT);
return result;
}
@@ -178,9 +181,6 @@
goto err_out;
}
- printk(KERN_INFO PFX AGP aperture is %dM @ 0x%lx\n,
- size_value, bridge-gart_bus_addr);
-
return 0;
err_out:
@@ -225,16 +225,31 @@
agp_copy_info
};
Re: Looking for some answers.
On Fri, 17 Dec 2004 10:35:42 +, Ian Molton [EMAIL PROTECTED] wrote: Hi. Is MergedFB going to replace xinerama in the long run? maybe. they will probably co-exist for the forseeable future. regular multi-head allows you do have two independant X servers while mergedfb always creates one single logical desktop. if not, will xinerama be able to use 3D / Xv properly on radeon (9000) in the near future? Xv should work fine with xinerama and mergedfb. There's only one overlay however so it will be sourced to whichever head more of it is on; crtc1 or 2. 3D only works with mergedfb. regular multihead and xinerama have issues with client side (direct) rendering, so 3D is disabled when xinerama is active. why doesnt radeon xinerama use mergedFB techniques to acieve its ends ? Xinerama itself is device independant. mergedfb provides it's own version of xinerama for window managers and xinerama aware apps so window sizing per head works properly. unless you need independant heads, there's no reason to use xinerama for multi-head when mergedfb is available, in my opinion at least. radeon mergedfb support is in xorg cvs and xorg 6.8.x let me know if you have any other questions. Alex --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 2.6.10-rc3 3/4] agpgart: allow multiple backends to be initialized
This new version reduces the number of changes required by users of the agpgart
such as drm to support the new api for multiple agp bridges.
The first patch doesn't touch any platform specific files and all current
platform
gart drivers will just work the same as they do now since the global
agp_bridge is still supported as the default bridge.
Summary for the 4 patches.
[1/4] Allow multiple backends to be initialized for agpgart
[2/4] Run Lindent on generic.c
[3/4] Patch drm code to work with modified agpgart api.
[4/4] Patch framebuffer code to work with modified agpgart api.
-
drmP.h |9 +
drm_agpsupport.h | 34 +-
drm_drv.h|4 ++--
drm_memory.h |4 ++--
4 files changed, 30 insertions(+), 21 deletions(-)
# This is a BitKeeper generated diff -Nru style patch.
#
# add drm support for new multiple agp bridge agpgart api
#
diff -Nru a/drivers/char/drm/drmP.h b/drivers/char/drm/drmP.h
--- a/drivers/char/drm/drmP.h 2004-12-17 12:12:56 -08:00
+++ b/drivers/char/drm/drmP.h 2004-12-17 12:12:56 -08:00
@@ -481,6 +481,7 @@
DRM_AGP_KERN agp_info;/** AGP device information */
drm_agp_mem_t *memory; /** memory entries */
unsigned long mode;/** AGP mode */
+ struct agp_bridge_data *bridge;
intenabled; /** whether the AGP bus as been
enabled */
intacquired;/** whether the AGP device has been
acquired */
unsigned long base;
@@ -778,7 +779,7 @@
drm_device_t *dev);
extern void DRM(ioremapfree)(void *pt, unsigned long size,
drm_device_t *dev);
-extern DRM_AGP_MEM *DRM(alloc_agp)(int pages, u32 type);
+extern DRM_AGP_MEM *DRM(alloc_agp)(struct agp_bridge_data *bridge, int
pages, u32 type);
extern int DRM(free_agp)(DRM_AGP_MEM *handle, int pages);
extern int DRM(bind_agp)(DRM_AGP_MEM *handle, unsigned int start);
extern int DRM(unbind_agp)(DRM_AGP_MEM *handle);
@@ -896,11 +897,11 @@
extern void DRM(vbl_send_signals)( drm_device_t *dev );
/* AGP/GART support (drm_agpsupport.h) */
-extern drm_agp_head_t *DRM(agp_init)(void);
+extern drm_agp_head_t *DRM(agp_init)(drm_device_t *dev);
extern void DRM(agp_uninit)(void);
extern intDRM(agp_acquire)(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern void DRM(agp_do_release)(void);
+extern void DRM(agp_do_release)(drm_device_t *dev);
extern intDRM(agp_release)(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
extern intDRM(agp_enable)(struct inode *inode, struct file *filp,
@@ -915,7 +916,7 @@
unsigned int cmd, unsigned long arg);
extern intDRM(agp_bind)(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern DRM_AGP_MEM*DRM(agp_allocate_memory)(size_t pages, u32 type);
+extern DRM_AGP_MEM*DRM(agp_allocate_memory)(struct agp_bridge_data
*bridge, size_t pages, u32 type);
extern intDRM(agp_free_memory)(DRM_AGP_MEM *handle);
extern intDRM(agp_bind_memory)(DRM_AGP_MEM *handle, off_t start);
extern intDRM(agp_unbind_memory)(DRM_AGP_MEM *handle);
diff -Nru a/drivers/char/drm/drm_agpsupport.h
b/drivers/char/drm/drm_agpsupport.h
--- a/drivers/char/drm/drm_agpsupport.h 2004-12-17 12:12:56 -08:00
+++ b/drivers/char/drm/drm_agpsupport.h 2004-12-17 12:12:56 -08:00
@@ -100,7 +100,7 @@
{
drm_file_t *priv = filp-private_data;
drm_device_t *dev= priv-dev;
- int retcode;
+
if (!dev-agp)
return -ENODEV;
@@ -108,8 +108,8 @@
return -EBUSY;
if (!drm_agp-acquire)
return -EINVAL;
- if ((retcode = drm_agp-acquire()))
- return retcode;
+ if (!(dev-agp-bridge = drm_agp-acquire(dev-pdev)))
+ return -ENODEV;
dev-agp-acquired = 1;
return 0;
}
@@ -133,7 +133,7 @@
if (!dev-agp || !dev-agp-acquired || !drm_agp-release)
return -EINVAL;
- drm_agp-release();
+ drm_agp-release(dev-agp-bridge);
dev-agp-acquired = 0;
return 0;
@@ -144,10 +144,10 @@
*
* Calls drm_agp-release().
*/
-void DRM(agp_do_release)(void)
+void DRM(agp_do_release)(drm_device_t *dev)
{
if (drm_agp-release)
- drm_agp-release();
+ drm_agp-release(dev-agp-bridge);
}
/**
@@ -176,7 +176,7 @@
return -EFAULT;
dev-agp-mode= mode.mode;
-
[patch 2.6.10-rc3 4/4] agpgart: allow multiple backends to be initialized
This new version reduces the number of changes required by users of the agpgart
such as drm to support the new api for multiple agp bridges.
The first patch doesn't touch any platform specific files and all current
platform
gart drivers will just work the same as they do now since the global
agp_bridge is still supported as the default bridge.
Summary for the 4 patches.
[1/4] Allow multiple backends to be initialized for agpgart
[2/4] Run Lindent on generic.c
[3/4] Patch drm code to work with modified agpgart api.
[4/4] Patch framebuffer code to work with modified agpgart api.
-
aty/radeon_pm.c |3 ++-
i810/i810_main.c | 17 +
intelfb/intelfbdrv.c | 23 ---
3 files changed, 23 insertions(+), 20 deletions(-)
# This is a BitKeeper generated diff -Nru style patch.
#
# add fb support for new multiple agp bridge agpgart api
#
diff -Nru a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
--- a/drivers/video/aty/radeon_pm.c 2004-12-17 12:53:56 -08:00
+++ b/drivers/video/aty/radeon_pm.c 2004-12-17 12:53:56 -08:00
@@ -870,7 +870,8 @@
* not for a module.
*/
#ifdef CONFIG_AGP
- agp_enable(0);
+ /* The bridge can be determined from agp_backend_acquire */
+ agp_enable(agp_bridge, 0);
#endif
fb_set_suspend(info, 1);
diff -Nru a/drivers/video/i810/i810_main.c b/drivers/video/i810/i810_main.c
--- a/drivers/video/i810/i810_main.c2004-12-17 12:53:56 -08:00
+++ b/drivers/video/i810/i810_main.c2004-12-17 12:53:56 -08:00
@@ -1591,40 +1591,41 @@
{
struct i810fb_par *par = (struct i810fb_par *) info-par;
int size;
+ struct agp_bridge_data *bridge;
i810_fix_offsets(par);
size = par-fb.size + par-iring.size;
- if (agp_backend_acquire()) {
+ if (!(bridge = agp_backend_acquire(par-dev))) {
printk(i810fb_alloc_fbmem: cannot acquire agpgart\n);
return -ENODEV;
}
if (!(par-i810_gtt.i810_fb_memory =
- agp_allocate_memory(size 12, AGP_NORMAL_MEMORY))) {
+ agp_allocate_memory(bridge, size 12, AGP_NORMAL_MEMORY))) {
printk(i810fb_alloc_fbmem: can't allocate framebuffer
memory\n);
- agp_backend_release();
+ agp_backend_release(bridge);
return -ENOMEM;
}
if (agp_bind_memory(par-i810_gtt.i810_fb_memory,
par-fb.offset)) {
printk(i810fb_alloc_fbmem: can't bind framebuffer memory\n);
- agp_backend_release();
+ agp_backend_release(bridge);
return -EBUSY;
}
if (!(par-i810_gtt.i810_cursor_memory =
- agp_allocate_memory(par-cursor_heap.size 12,
+ agp_allocate_memory(bridge, par-cursor_heap.size 12,
AGP_PHYSICAL_MEMORY))) {
printk(i810fb_alloc_cursormem: can't allocate
cursor memory\n);
- agp_backend_release();
+ agp_backend_release(bridge);
return -ENOMEM;
}
if (agp_bind_memory(par-i810_gtt.i810_cursor_memory,
par-cursor_heap.offset)) {
printk(i810fb_alloc_cursormem: cannot bind cursor memory\n);
- agp_backend_release();
+ agp_backend_release(bridge);
return -EBUSY;
}
@@ -1632,7 +1633,7 @@
i810_fix_pointers(par);
- agp_backend_release();
+ agp_backend_release(bridge);
return 0;
}
diff -Nru a/drivers/video/intelfb/intelfbdrv.c
b/drivers/video/intelfb/intelfbdrv.c
--- a/drivers/video/intelfb/intelfbdrv.c2004-12-17 12:53:56 -08:00
+++ b/drivers/video/intelfb/intelfbdrv.c2004-12-17 12:53:56 -08:00
@@ -470,6 +470,7 @@
struct agp_kern_info gtt_info;
int agp_memtype;
const char *s;
+ struct agp_bridge_data *bridge;
DBG_MSG(intelfb_pci_register\n);
@@ -605,16 +606,16 @@
}
/* Use agpgart to manage the GATT */
- if (agp_backend_acquire()) {
+ if (!(bridge = agp_backend_acquire(pdev))) {
ERR_MSG(cannot acquire agp\n);
cleanup(dinfo);
return -ENODEV;
}
/* get the current gatt info */
- if (agp_copy_info(gtt_info)) {
+ if (agp_copy_info(bridge, gtt_info)) {
ERR_MSG(cannot get agp info\n);
- agp_backend_release();
+ agp_backend_release(bridge);
cleanup(dinfo);
return -ENODEV;
}
@@ -637,17 +638,17 @@
/* Allocate memories (which aren't stolen) */
if (dinfo-accel) {
if (!(dinfo-gtt_ring_mem =
-
Post-processing hook for vertex setup code
Hi,
I'm trying to get projective textures working on hardware that doesn't
support homogenous texture coordinates with the new vertex setup code
(t_vertex.[ch]). The problem with this is that the W coordinate of the
hardware vertex must be computed from two vertex attributes, which is
why the new vertex setup code can't generated it directly.
The solution I'm proposing emits homogenous texture coordinates and then
calls a vertex post-processing hook in the driver that can compute W and
2D tex coords suitable for my crippled hardware from homogenous tex
coords.
I'm attaching two patches. The first one implements the
driver-independent functionality for hooking up a post-processing
function. The second one demonstrates the changes to the Savage driver
to support projective texturing using the post-processing hook.
I'd appreciate feedback (Keith?) if this is good for CVS or if there are
other/better ideas for solving the same problem.
Thanks,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- ./t_context.h.~1.64.~ 2004-07-23 16:18:37.0 +0200
+++ ./t_context.h 2004-12-17 19:56:09.0 +0100
@@ -539,6 +539,10 @@
GLuint start,
GLuint end, void *dest );
+typedef void (*tnl_postproc_func)( GLcontext *ctx,
+ GLuint start,
+ GLuint end, void *dest );
+
/**
* Describes how to convert/move a vertex attribute from a vertex array
@@ -631,6 +635,7 @@
tnl_emit_func emit;
tnl_interp_func interp;
tnl_copy_pv_func copy_pv;
+ tnl_postproc_func postproc;
struct tnl_clipspace_codegen codegen;
};
--- ./t_vertex.c.~1.24.~ 2004-10-27 11:12:58.0 +0200
+++ ./t_vertex.c 2004-12-17 20:07:30.0 +0100
@@ -1177,6 +1177,7 @@
vtx-emit = 0;
vtx-interp = choose_interp_func;
vtx-copy_pv = choose_copy_pv_func;
+ vtx-postproc = 0;
vtx-new_inputs = ~0;
for (j = 0, i = 0; i nr; i++) {
@@ -1225,6 +1226,12 @@
}
+void _tnl_install_postproc( GLcontext *ctx, tnl_postproc_func func )
+{
+ struct tnl_clipspace *vtx = GET_VERTEX_STATE(ctx);
+ vtx-postproc = func;
+}
+
void _tnl_invalidate_vertices( GLcontext *ctx, GLuint newinputs )
{
@@ -1245,8 +1252,11 @@
newinputs |= vtx-new_inputs;
vtx-new_inputs = 0;
- if (newinputs)
+ if (newinputs) {
do_emit( ctx, start, end, vDest );
+ if (vtx-postproc)
+ vtx-postproc( ctx, start, end, vDest );
+ }
}
--- ./t_vertex.h.~1.12.~ 2004-10-27 11:12:58.0 +0200
+++ ./t_vertex.h 2004-12-17 20:07:15.0 +0100
@@ -103,6 +103,9 @@
GLuint nr, const GLfloat *vp,
GLuint unpacked_size );
+extern void _tnl_install_postproc( GLcontext *ctx,
+ tnl_postproc_func func);
+
--- ./savagedma.c.~1.4.~ 2004-12-15 16:37:19.0 +0100
+++ ./savagedma.c 2004-12-17 21:35:56.0 +0100
@@ -312,8 +312,8 @@
};
void savageFakeVertices (savageContextPtr imesa, drmBufPtr buffer) {
-GLuint vertexStride = imesa-vertex_size; /* stride in dwords */
-GLuint vertexSize = imesa-vertex_size; /* the real vertex size in dwords */
+GLuint vertexStride = imesa-HwVertexSize; /* stride in dwords */
+GLuint vertexSize = imesa-HwVertexSize; /* the real vertex size in dwords */
GLuint nVertices = buffer-used / (vertexStride*4);
u_int32_t *data = (u_int32_t*)buffer-address;
u_int32_t vertexFormat = imesa-DrawPrimitiveCmd SAVAGE_HW_SKIPFLAGS;
--- ./savagecontext.h.~1.11.~ 2004-12-17 16:06:50.0 +0100
+++ ./savagecontext.h 2004-12-17 20:35:19.0 +0100
@@ -179,6 +179,7 @@
GLenum render_primitive;
GLuint DrawPrimitiveCmd;
+ GLuint HwVertexSize;
/* Fallback rasterization functions
*/
--- ./savagetris.c.~1.16.~ 2004-12-17 16:34:52.0 +0100
+++ ./savagetris.c 2004-12-17 21:57:58.0 +0100
@@ -99,7 +99,7 @@
savageVertexPtr v0,
savageVertexPtr v1,
savageVertexPtr v2) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize;
u_int32_t *vb = savageAllocDmaLow (imesa, 3*4*vertsize);
GLuint j;
@@ -113,7 +113,7 @@
savageVertexPtr v1,
savageVertexPtr v2,
savageVertexPtr v3) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize;
u_int32_t *vb = savageAllocDmaLow (imesa, 6*4*vertsize);
GLuint j;
@@ -127,7 +127,7 @@
static __inline__ void savage_draw_point (savageContextPtr imesa,
savageVertexPtr tmp) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize;
u_int32_t *vb = savageAllocDmaLow (imesa, 6*4*vertsize);
const GLfloat x = tmp-v.x;
const GLfloat y = tmp-v.y;
@@ -162,7 +162,7 @@
static __inline__ void savage_draw_line (savageContextPtr imesa,
savageVertexPtr v0,
savageVertexPtr v1 ) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize;
Re: Post-processing hook for vertex setup code
Felix Kühling wrote: Hi, I'm trying to get projective textures working on hardware that doesn't support homogenous texture coordinates with the new vertex setup code (t_vertex.[ch]). The problem with this is that the W coordinate of the hardware vertex must be computed from two vertex attributes, which is why the new vertex setup code can't generated it directly. The solution I'm proposing emits homogenous texture coordinates and then calls a vertex post-processing hook in the driver that can compute W and 2D tex coords suitable for my crippled hardware from homogenous tex coords. I'm attaching two patches. The first one implements the driver-independent functionality for hooking up a post-processing function. The second one demonstrates the changes to the Savage driver to support projective texturing using the post-processing hook. I'd appreciate feedback (Keith?) if this is good for CVS or if there are other/better ideas for solving the same problem. It's a hack, of course, but hardware like this really makes it difficult to keep things nice. There are quite a few drivers that are stuck waiting for a solution to this issue. One question is what happens with the 'rastersetup-to-dma' fast render stages for unclipped primitives? It looks like in this approach you emit vertices from t_vb.c which are 1 dword larger than hardware expects and then fix things up afterwards, right? So you'd want to make sure you weren't doing that into a dma buffer... Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right? Also, the above point about two different vertex sizes isn't really clear in the code could use some explanation. In balance, I think I prefer a slightly different solution to the problem: 1) Make sure rastersetup-to-dma isn't used with these types of vertices. 2) Emit vertices with a seperate 'q' coordinate, as if the hardware supported projective-textured vertives. 3) Create point, line, triangle functions which translate from idealized to hardware vertices and make sure that they get used for all primitives. This probably works out slightly slower but is going to be much easier to make work correctly, and there is a much better chance of getting a correct result. Keith --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Post-processing hook for vertex setup code
Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59: Felix Kühling wrote: Hi, I'm trying to get projective textures working on hardware that doesn't support homogenous texture coordinates with the new vertex setup code (t_vertex.[ch]). The problem with this is that the W coordinate of the hardware vertex must be computed from two vertex attributes, which is why the new vertex setup code can't generated it directly. The solution I'm proposing emits homogenous texture coordinates and then calls a vertex post-processing hook in the driver that can compute W and 2D tex coords suitable for my crippled hardware from homogenous tex coords. I'm attaching two patches. The first one implements the driver-independent functionality for hooking up a post-processing function. The second one demonstrates the changes to the Savage driver to support projective texturing using the post-processing hook. I'd appreciate feedback (Keith?) if this is good for CVS or if there are other/better ideas for solving the same problem. It's a hack, of course, but hardware like this really makes it difficult to keep things nice. There are quite a few drivers that are stuck waiting for a solution to this issue. One question is what happens with the 'rastersetup-to-dma' fast render stages for unclipped primitives? It looks like in this approach you emit vertices from t_vb.c which are 1 dword larger than hardware expects and then fix things up afterwards, right? So you'd want to make sure you weren't doing that into a dma buffer... True. But the savage driver doesn't do that (yet). Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right? Right. But that would have been broken with t_dd_vbtmp.h too. ;-) Also, the above point about two different vertex sizes isn't really clear in the code could use some explanation. In balance, I think I prefer a slightly different solution to the problem: 1) Make sure rastersetup-to-dma isn't used with these types of vertices. If I understand you correctly you're referring to what radeon_swtcl.c does in the radeon driver. AFAIK Savage and MGA are affected by this projective texture hack (maybe also r128). And neither have this kind of fast path (ATM). If there was a fast path then one would have to make sure to fall back to the _tnl_render_stage if one needs to fake homogenous texture coordinates. 2) Emit vertices with a seperate 'q' coordinate, as if the hardware supported projective-textured vertives. That's what I'm doing already. 3) Create point, line, triangle functions which translate from idealized to hardware vertices and make sure that they get used for all primitives. Ok. This seems to be the only real difference to my approach. Also this way no changes to the generic TNL-code would be needed at all. Actually that's not such a bad idea after all. This probably works out slightly slower but is going to be much easier to make work correctly, and there is a much better chance of getting a correct result. Keith Thanks for the feedback. Let's see if I can come up with an elegant hack along these lines. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Looking for some answers.
--- Ian Molton [EMAIL PROTECTED] wrote: Hi. Is MergedFB going to replace xinerama in the long run? MergedFB only workes on hardware that supports it, where both heads can share the same continious framebuffer. This can only be done if the DACs(heads) share the same video memory. if not, will xinerama be able to use 3D / Xv properly on radeon (9000) in the near future? I don't think there are any plans to support 3D for xinerama. why doesnt radeon xinerama use mergedFB techniques to acieve its ends ? The only big hurdel is wather or not the heads share enuff videomemory for the entire FB. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Send a seasonal email greeting and help others. Do good. http://celebrity.mail.yahoo.com --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: Post-processing hook for vertex setup code
Felix Kühling wrote: Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59: Felix Kühling wrote: Hi, I'm trying to get projective textures working on hardware that doesn't support homogenous texture coordinates with the new vertex setup code (t_vertex.[ch]). The problem with this is that the W coordinate of the hardware vertex must be computed from two vertex attributes, which is why the new vertex setup code can't generated it directly. The solution I'm proposing emits homogenous texture coordinates and then calls a vertex post-processing hook in the driver that can compute W and 2D tex coords suitable for my crippled hardware from homogenous tex coords. I'm attaching two patches. The first one implements the driver-independent functionality for hooking up a post-processing function. The second one demonstrates the changes to the Savage driver to support projective texturing using the post-processing hook. I'd appreciate feedback (Keith?) if this is good for CVS or if there are other/better ideas for solving the same problem. It's a hack, of course, but hardware like this really makes it difficult to keep things nice. There are quite a few drivers that are stuck waiting for a solution to this issue. One question is what happens with the 'rastersetup-to-dma' fast render stages for unclipped primitives? It looks like in this approach you emit vertices from t_vb.c which are 1 dword larger than hardware expects and then fix things up afterwards, right? So you'd want to make sure you weren't doing that into a dma buffer... True. But the savage driver doesn't do that (yet). Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right? Right. But that would have been broken with t_dd_vbtmp.h too. ;-) No, t_dd_vbtmp.h *does* undo the projection, look around line 534. Keith --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Post-processing hook for vertex setup code
Felix Kühling wrote: Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59: Felix Kühling wrote: Hi, I'm trying to get projective textures working on hardware that doesn't support homogenous texture coordinates with the new vertex setup code (t_vertex.[ch]). The problem with this is that the W coordinate of the hardware vertex must be computed from two vertex attributes, which is why the new vertex setup code can't generated it directly. The solution I'm proposing emits homogenous texture coordinates and then calls a vertex post-processing hook in the driver that can compute W and 2D tex coords suitable for my crippled hardware from homogenous tex coords. I'm attaching two patches. The first one implements the driver-independent functionality for hooking up a post-processing function. The second one demonstrates the changes to the Savage driver to support projective texturing using the post-processing hook. I'd appreciate feedback (Keith?) if this is good for CVS or if there are other/better ideas for solving the same problem. It's a hack, of course, but hardware like this really makes it difficult to keep things nice. There are quite a few drivers that are stuck waiting for a solution to this issue. One question is what happens with the 'rastersetup-to-dma' fast render stages for unclipped primitives? It looks like in this approach you emit vertices from t_vb.c which are 1 dword larger than hardware expects and then fix things up afterwards, right? So you'd want to make sure you weren't doing that into a dma buffer... True. But the savage driver doesn't do that (yet). Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right? Right. But that would have been broken with t_dd_vbtmp.h too. ;-) Also, the above point about two different vertex sizes isn't really clear in the code could use some explanation. In balance, I think I prefer a slightly different solution to the problem: 1) Make sure rastersetup-to-dma isn't used with these types of vertices. If I understand you correctly you're referring to what radeon_swtcl.c does in the radeon driver. AFAIK Savage and MGA are affected by this projective texture hack (maybe also r128). And neither have this kind of fast path (ATM). If there was a fast path then one would have to make sure to fall back to the _tnl_render_stage if one needs to fake homogenous texture coordinates. I can think of the i810 and mga which both have this projective texture issue *and* have the fast path (in i810render.c and mga_render.c respectively). It (used to be?) a worthwhile optimization. Keith --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2099] New: Doom3 demo crashed with error
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2099 Summary: Doom3 demo crashed with error Product: Mesa Version: 6.1 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Drivers/DRI/r200 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I tried to run the DOOM 3 demo and I got. using ARB_vertex_buffer_object memory using ARB renderSystem Mesa implementation error: unexpected texture format in r200ChooseTextureFormat Please report to the Mesa bug database at www.mesa3d.org doom.x86: texstore.c:2260: _mesa_store_compressed_teximage2d: Assertion `texImage-TexFormat' failed. signal caught: Aborted si_code -6 I'm running FedoraCore 3 on Radeon9200 with xorg version 6.8.1-12.FC3.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2099] Doom3 demo crashed with error
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2099 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 18:59 --- fixed in CVS, and in Mesa 6.2.1 which is in the Xorg 6.8.2 release candidate. r200_dri.so does not support S3TC textures by default due to patent licensing issues. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1707] r200 Radeon driver and Wings 3D
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1707 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 19:13 --- Does it work with tcl_mode=0? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1707] r200 Radeon driver and Wings 3D
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1707 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 23:49 --- I set tcl_mode=0 in my ~/.drirc Nothing changed, problem still persists. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
