Re: [Mesa3d-dev] Figuring out R300_VAP_CNTL
Not sure if you are still collecting ... but here you go 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 ND [Radeon 9700 Pro] (prog-if 00 [VGA]) Subsystem: Elsa AG Unknown device 0c90 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r200] minor minor minor cleanups
Hi list, attached are few fixes for "issues" I found while browsing through the r200 DRI code. Bye, Christoph 0001-r200-Drop-CVS-header-from-files.patch Description: application/mbox 0002-r200-reenable-debug-output.patch Description: application/mbox 0003-r200-set-anisotropy-filtering-to-1-instead-of-16-fo.patch Description: application/mbox - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 minor cleanups
Am Montag, den 14.05.2007, 22:53 +0200 schrieb Roland Scheidegger: > Christoph Brill wrote: > > Hi, > > > > find attached some minor cleanups I did while comparing r200 and r300 > > code. Most of them are indention and cosmetical changes. Only real > > changes are that I replaced som > > > > if (0) > > > > with > > > > if (R200_DEBUG & DEBUG_TEXTURE) > > > > It generally reduces the diff between r200 and r300. That's it. > > > > Review and commit please, > > Christoph Brill > > > Hmm, personally I'm not too happy with kernel-style indentation (and > worse, some parts of the driver but not others converted to it). But > maybe that's just me. If you're truely going to unify the drivers, there > is obviously no way around that (though you could just convert r300 to > use style of radeon/r200...) but if the files are still separate anyway > I don't see much point. > Other opinions? > > Roland I don't really have an opinion on that. The only thing I dislike in the r200 code is that it uses spaces for indents. But that's only my opinion. We can choose whatever indention you like. Note: I'm not 100% sure if merging r300 and r200 code is usefull or even possible. I generally think there is a high amount of redundancy that could be unified. But I need to check that against radeon first before I really continue to do so. I'd rather say to keep my patches out of git for now until a decision for indention was made. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R200 minor cleanups
Hi, find attached some minor cleanups I did while comparing r200 and r300 code. Most of them are indention and cosmetical changes. Only real changes are that I replaced som if (0) with if (R200_DEBUG & DEBUG_TEXTURE) It generally reduces the diff between r200 and r300. That's it. Review and commit please, Christoph Brill r200-updates.tar.bz2 Description: application/bzip-compressed-tar - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] minor cleanups
Hi list, I've been browsing through the code to get more in touch with it. On my way I added few doxygen comments and removed the use of a unnecessary function. The removal was agreed by Jerome Glisse. Please check and push these. Thanks in advance, Christoph Brill 0001-Add-few-doxygen-comments-to-r300_context.h.patch Description: application/mbox 0002-Few-doxgen-comments.patch Description: application/mbox - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 cleanup questions
I reviewed the cleanup done by Olliver McFadden and had the following
questions:
-int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim)
+static int r300NumVerts(r300ContextPtr rmesa, int num_verts, int prim)
Is it necessary/usefull that the function is static?
-/* Immediate implementation has been removed from CVS. */
-
-/* vertex buffer implementation */
-
-static void inline fire_EB(r300ContextPtr rmesa, unsigned long addr
+static void inline r300FireEB(r300ContextPtr rmesa, unsigned long addr
Why move all the comments to the head of the file. IMO the method should
have a doxygen comment that states it is the vertex buffer
implementation of fire_EB, right?
-if (num_verts > 65535) { /* not implemented yet */
+if (num_verts > 65535) {
Comments like this should be kept. Otherwise it looks like a hardware
limitation while the limitation can be worked around or the limitation
does not exist.
Last but not least is
r300_foo_bar
preferred or
r300FooBar
Which is the one mesa uses?
Otherwise thumbs up for starting to cleanup code... on of the most
unthankfull jobs :-)
Regards,
Christoph Brill
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] TiRDC #4
Hi list, I proudly present the 4th issue of "The irregular Radeon Development Companion". This is an aggregation of the DRI development events happening on IRC, on the mailing lists and on blogs. It is mainly focused on R300, but also sums up other parts of DRM/DRI and sometimes even DDX. Feel free to read what happened lately and give feedback about what you think of TiRDC. The current issue is at: http://dri.freedesktop.org/wiki/Radeon_20Companion_204 and older versions can be found at http://dri.freedesktop.org/wiki/R300 Thanks for reading, Christoph Brill (TiRDC author) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH]
Hi list,
currently the drm does not use the return values of several methods.
This patch tries to add some checks. But I guess it's completely
wrong :-)
Regards,
Christoph Brill
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index ff9b29e..9dd0038 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -329,9 +329,11 @@ int drm_init(struct drm_driver *driver,
}
}
- if (!drm_fb_loaded)
- pci_register_driver(&driver->pci_driver);
- else {
+ if (!drm_fb_loaded) {
+ if (pci_register_driver(&driver->pci_driver) < 0) {
+ DRM_ERROR("could not pci_register_driver\n");
+ }
+ } else {
for (i = 0; pciidlist[i].vendor != 0; i++) {
pid = &pciidlist[i];
diff --git a/linux-core/drm_stub.c b/linux-core/drm_stub.c
index 348cd2c..e20bfce 100644
--- a/linux-core/drm_stub.c
+++ b/linux-core/drm_stub.c
@@ -233,10 +233,16 @@ int drm_get_dev(struct pci_dev *pdev, const struct pci_device_id *ent,
if (!drm_fb_loaded) {
pci_set_drvdata(pdev, dev);
- pci_request_regions(pdev, driver->pci_driver.name);
+ if (pci_request_regions(pdev, driver->pci_driver.name) < 0) {
+ DRM_ERROR("could not pci_request_regions\n");
+ return -ENOMEM;
+ }
}
- pci_enable_device(pdev);
+ if (!pci_enable_device(pdev)) {
+ DRM_ERROR("could not pci_enable_device\n");
+ return -ENOMEM;
+ }
pci_set_master(pdev);
if ((ret = drm_fill_in_dev(dev, pdev, ent, driver))) {
diff --git a/linux-core/drm_sysfs.c b/linux-core/drm_sysfs.c
index ace0778..182a195 100644
--- a/linux-core/drm_sysfs.c
+++ b/linux-core/drm_sysfs.c
@@ -93,7 +93,11 @@ struct drm_sysfs_class *drm_sysfs_create(struct module *owner, char *name)
retval = class_register(&cs->class);
if (retval)
goto error;
- class_create_file(&cs->class, &class_attr_version);
+ if (class_create_file(&cs->class, &class_attr_version) < 0) {
+ DRM_ERROR("could not class_create_file\n");
+ retval = -ENOMEM;
+ goto error;
+ }
return cs;
@@ -170,11 +174,20 @@ struct class_device *drm_sysfs_device_add(struct drm_sysfs_class *cs,
if (retval)
goto error;
- class_device_create_file(&s_dev->class_dev, &cs->attr);
+ if (class_device_create_file(&s_dev->class_dev, &cs->attr) < 0) {
+ DRM_ERROR("could not class_device_create_file\n");
+ retval = -ENOMEM;
+ goto error;
+ }
+
class_set_devdata(&s_dev->class_dev, head);
for (i = 0; i < ARRAY_SIZE(class_device_attrs); i++)
- class_device_create_file(&s_dev->class_dev, &class_device_attrs[i]);
+ if (class_device_create_file(&s_dev->class_dev, &class_device_attrs[i]) < 0) {
+ DRM_ERROR("could not class_device_create_file\n");
+ retval = -ENOMEM;
+ goto error;
+ }
return &s_dev->class_dev;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Use constants during reset
Attached is a patch to use some more constants in r300ResetHwState() or r300_state.c. Maybe some of the unk registers in r300_hw_state of r300_context.h should be renamed, too. diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_cmdbuf.c ./r300_cmdbuf.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_cmdbuf.c 2007-02-26 21:18:39.0 +0100 +++ ./r300_cmdbuf.c 2007-02-26 21:38:28.0 +0100 @@ -292,13 +292,13 @@ ALLOC_STATE( vpt, always, R300_VPT_CMDSIZE, "vpt", 0 ); r300->hw.vpt.cmd[R300_VPT_CMD_0] = cmdpacket0(R300_SE_VPORT_XSCALE, 6); ALLOC_STATE( unk2080, always, 2, "unk2080", 0 ); - r300->hw.unk2080.cmd[0] = cmdpacket0(0x2080, 1); + r300->hw.unk2080.cmd[0] = cmdpacket0(R300_VAP_CNTL, 1); ALLOC_STATE( vte, always, 3, "vte", 0 ); r300->hw.vte.cmd[0] = cmdpacket0(R300_SE_VTE_CNTL, 2); ALLOC_STATE( unk2134, always, 3, "unk2134", 0 ); r300->hw.unk2134.cmd[0] = cmdpacket0(0x2134, 2); ALLOC_STATE( unk2140, always, 2, "unk2140", 0 ); - r300->hw.unk2140.cmd[0] = cmdpacket0(0x2140, 1); + r300->hw.unk2140.cmd[0] = cmdpacket0(R300_VAP_CNTL_STATUS, 1); ALLOC_STATE( vir[0], variable, R300_VIR_CMDSIZE, "vir/0", 0 ); r300->hw.vir[0].cmd[R300_VIR_CMD_0] = cmdpacket0(R300_VAP_INPUT_ROUTE_0_0, 1); ALLOC_STATE( vir[1], variable, R300_VIR_CMDSIZE, "vir/1", 1 ); @@ -308,11 +308,11 @@ ALLOC_STATE( unk21DC, always, 2, "unk21DC", 0 ); r300->hw.unk21DC.cmd[0] = cmdpacket0(0x21DC, 1); ALLOC_STATE( unk221C, always, 2, "unk221C", 0 ); - r300->hw.unk221C.cmd[0] = cmdpacket0(0x221C, 1); + r300->hw.unk221C.cmd[0] = cmdpacket0(R300_VAP_UNKNOWN_221C, 1); ALLOC_STATE( unk2220, always, 5, "unk2220", 0 ); r300->hw.unk2220.cmd[0] = cmdpacket0(0x2220, 4); ALLOC_STATE( unk2288, always, 2, "unk2288", 0 ); - r300->hw.unk2288.cmd[0] = cmdpacket0(0x2288, 1); + r300->hw.unk2288.cmd[0] = cmdpacket0(R300_VAP_UNKNOWN_2288, 1); ALLOC_STATE( vof, always, R300_VOF_CMDSIZE, "vof", 0 ); r300->hw.vof.cmd[R300_VOF_CMD_0] = cmdpacket0(R300_VAP_OUTPUT_VTX_FMT_0, 2); ALLOC_STATE( pvs, always, R300_PVS_CMDSIZE, "pvs", 0 ); @@ -336,9 +336,9 @@ ALLOC_STATE( unk4260, always, 4, "unk4260", 0 ); r300->hw.unk4260.cmd[0] = cmdpacket0(0x4260, 3); ALLOC_STATE( unk4274, always, 5, "unk4274", 0 ); - r300->hw.unk4274.cmd[0] = cmdpacket0(0x4274, 4); + r300->hw.unk4274.cmd[0] = cmdpacket0(R300_RE_SHADE, 4); ALLOC_STATE( unk4288, always, 4, "unk4288", 0 ); - r300->hw.unk4288.cmd[0] = cmdpacket0(0x4288, 3); + r300->hw.unk4288.cmd[0] = cmdpacket0(R300_RE_POLYGON_MODE, 3); ALLOC_STATE( fogp, always, 3, "fogp", 0 ); r300->hw.fogp.cmd[0] = cmdpacket0(R300_RE_FOG_SCALE, 2); ALLOC_STATE( unk42A0, always, 2, "unk42A0", 0 ); @@ -346,7 +346,7 @@ ALLOC_STATE( zbs, always, R300_ZBS_CMDSIZE, "zbs", 0 ); r300->hw.zbs.cmd[R300_ZBS_CMD_0] = cmdpacket0(R300_RE_ZBIAS_T_FACTOR, 4); ALLOC_STATE( unk42B4, always, 2, "unk42B4", 0 ); - r300->hw.unk42B4.cmd[0] = cmdpacket0(0x42B4, 1); + r300->hw.unk42B4.cmd[0] = cmdpacket0(R300_RE_OCCLUSION_CNTL, 1); ALLOC_STATE( cul, always, R300_CUL_CMDSIZE, "cul", 0 ); r300->hw.cul.cmd[R300_CUL_CMD_0] = cmdpacket0(R300_RE_CULL_CNTL, 1); ALLOC_STATE( unk42C0, always, 3, "unk42C0", 0 ); @@ -393,7 +393,7 @@ ALLOC_STATE( cmk, always, R300_CMK_CMDSIZE, "cmk", 0 ); r300->hw.cmk.cmd[R300_CMK_CMD_0] = cmdpacket0(R300_RB3D_COLORMASK, 1); ALLOC_STATE( unk4E10, always, 4, "unk4E10", 0 ); - r300->hw.unk4E10.cmd[0] = cmdpacket0(0x4E10, 3); + r300->hw.unk4E10.cmd[0] = cmdpacket0(R300_RB3D_BLEND_COLOR, 3); ALLOC_STATE( cb, always, R300_CB_CMDSIZE, "cb", 0 ); r300->hw.cb.cmd[R300_CB_CMD_0] = cmdpacket0(R300_RB3D_COLOROFFSET0, 1); r300->hw.cb.cmd[R300_CB_CMD_1] = cmdpacket0(R300_RB3D_COLORPITCH0, 1); @@ -406,7 +406,7 @@ ALLOC_STATE( zs, always, R300_ZS_CMDSIZE, "zstencil", 0 ); r300->hw.zs.cmd[R300_ZS_CMD_0] = cmdpacket0(R300_RB3D_ZSTENCIL_CNTL_0, 3); ALLOC_STATE( unk4F10, always, 5, "unk4F10", 0 ); - r300->hw.unk4F10.cmd[0] = cmdpacket0(0x4F10, 4); + r300->hw.unk4F10.cmd[0] = cmdpacket0(R300_RB3D_ZSTENCIL_FORMAT, 4); ALLOC_STATE( zb, always, R300_ZB_CMDSIZE, "zb", 0 ); r300->hw.zb.cmd[R300_ZB_CMD_0] = cmdpacket0(R300_RB3D_DEPTHOFFSET, 2); ALLOC_STATE( unk4F28, always, 2, "unk4F28", 0 ); diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h ./r300_reg.h --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h 2007-02-26 21:18:37.0 +0100 +++ ./r300_reg.h 2007-02-26 21:36:43.0 +0100 @@ -544,6 +544,9 @@ /* Some sort of scale or clamp value for texcoordless textures. */ #define R300_RE_UNK4238 0x4238 +/* Something shade related */ +#define R300_RE_SHADE 0x4274 + #define R300_RE_SHADE_MODEL 0x4278 # define R300_RE_SHADE_MODEL_SMOOTH 0x3 # define R300_RE_SHADE_MODEL_FLAT 0x39595 @@ -1279,6 +1282,7 @@ # define R300_BLEND_MASK (63) # define R300_SRC_BLEND_SHIFT (16) # define R300_D
[PATCHES] Misc R300 cleanup towards a better r300_reg.h
Attached are two patches that: - define 0x4f18 as R300_RB3D_UNKOWN_4F18 - copy over 1 define from r200 as R300_VAP_CNTL - rename R300_VAP_CNTL to R300_VAP_CNTL_STATUS to be the same as r200 (both unused in r300 code) On #dri-devel there was discussion about similarities in the lower register numbers (up to 0x2200 iirc). Can someone tell if these thoughts might be correct? Also there was discussion on getting information about the blob from tracing the win32 driver. Anyone got some information on how to do so? diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c ./r300_ioctl.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c 2007-02-26 16:48:38.0 +0100 +++ ./r300_ioctl.c 2007-02-26 16:53:22.0 +0100 @@ -227,7 +227,7 @@ e32(0); R300_STATECHANGE(r300, unk221C); - reg_start(0x221C, 0); + reg_start(R300_VAP_UNKNOWN_221C, 0); e32(R300_221C_CLEAR); R300_STATECHANGE(r300, ps); diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h ./r300_reg.h --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h 2007-02-26 16:48:40.0 +0100 +++ ./r300_reg.h 2007-02-26 17:46:22.0 +0100 @@ -63,6 +63,12 @@ #define R300_SE_VPORT_ZOFFSET 0x1DAC +/* + * Vertex Array Processing (VAP) Control + * Stolen from r200 code from Christoph Brill (It's a guess!) + */ +#define R300_VAP_CNTL 0x2080 + /* This register is written directly and also starts data section * in many 3d CP_PACKET3's */ @@ -135,7 +141,7 @@ /* gap */ -#define R300_VAP_CNTL 0x2140 +#define R300_VAP_CNTL_STATUS 0x2140 # define R300_VC_NO_SWAP (0 << 0) # define R300_VC_16BIT_SWAP (1 << 0) # define R300_VC_32BIT_SWAP (2 << 0) diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/radeon_mm.c ./radeon_mm.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/radeon_mm.c 2007-01-20 21:07:09.0 +0100 +++ ./radeon_mm.c 2007-02-26 16:57:56.0 +0100 @@ -283,7 +283,7 @@ size -= cp_size; } - reg_start(0x4e4c,0); + reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); reg_start(0x342c,0); diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c ./r300_ioctl.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_ioctl.c 2007-02-26 10:55:02.0 +0100 +++ ./r300_ioctl.c 2007-02-26 16:41:10.0 +0100 @@ -163,9 +163,8 @@ reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); - - reg_start(0x4f18,0); + reg_start(R300_RB3D_UNKOWN_4F18,0); e32(0x0003); cp_wait(rmesa, R300_WAIT_3D | R300_WAIT_3D_CLEAN); } diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h ./r300_reg.h --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_reg.h 2007-02-26 16:44:19.0 +0100 +++ ./r300_reg.h 2007-02-26 16:40:41.0 +0100 @@ -1309,7 +1309,7 @@ /* gap */ /* Guess by Vladimir. - * Set to 0A before 3D operations, set to 02 afterwards. + * Set to 0A before 3D operations, set to 0A (was 02) afterwards. */ #define R300_RB3D_DSTCACHE_CTLSTAT 0x4E4C # define R300_RB3D_DSTCACHE_02 0x0002 @@ -1382,6 +1382,12 @@ # define R300_EARLY_Z_DISABLE (0 << 0) # define R300_EARLY_Z_ENABLE (1 << 0) +/* + * Set to 03 before 3D operations, set to 03 (was 01) afterwards. + */ +#define R300_RB3D_UNKOWN_4F18 0x4F18 + + /* gap */ #define R300_RB3D_DEPTHOFFSET 0x4F20 diff -Naur /usr/src/mesa/src/mesa/drivers/dri/r300/r300_render.c ./r300_render.c --- /usr/src/mesa/src/mesa/drivers/dri/r300/r300_render.c 2007-02-26 10:55:02.0 +0100 +++ ./r300_render.c 2007-02-26 16:39:03.0 +0100 @@ -346,7 +346,7 @@ reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); - reg_start(0x4f18,0); + reg_start(R300_RB3D_UNKOWN_4F18,0); e32(0x0003); r300EmitState(rmesa); @@ -362,7 +362,7 @@ reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a/*0x2*/); - reg_start(0x4f18,0); + reg_start(R300_RB3D_UNKOWN_4F18,0); e32(0x0003/*0x1*/); #ifdef USER_BUFFERS - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R300 early Z cleanup
Attached is a revised patch with few comments (because of missing bit
shifts) from agd5f in #dri-devel. Thanks!
diff --git a/src/mesa/drivers/dri/r300/r300_reg.h b/src/mesa/drivers/dri/r300/r300_reg.h
index 9f636ec..6abcfa4 100644
--- a/src/mesa/drivers/dri/r300/r300_reg.h
+++ b/src/mesa/drivers/dri/r300/r300_reg.h
@@ -1378,6 +1378,10 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
/* 16 bit format or some aditional bit ? */
# define R300_DEPTH_FORMAT_UNK32 (32 << 0)
+#define R300_RB3D_EARLY_Z 0x4F14
+# define R300_EARLY_Z_DISABLE (0 << 0)
+# define R300_EARLY_Z_ENABLE (1 << 0)
+
/* gap */
#define R300_RB3D_DEPTHOFFSET 0x4F20
diff --git a/src/mesa/drivers/dri/r300/r300_state.c b/src/mesa/drivers/dri/r300/r300_state.c
index b30ece1..0e33e51 100644
--- a/src/mesa/drivers/dri/r300/r300_state.c
+++ b/src/mesa/drivers/dri/r300/r300_state.c
@@ -328,24 +328,24 @@ static void r300UpdateCulling(GLcontext* ctx)
static void update_early_z(GLcontext *ctx)
{
- /* updates register 0x4f14
- if depth test is not enabled it should be 0x
- if depth is enabled and alpha not it should be 0x0001
- if depth and alpha is enabled it should be 0x
+ /* updates register R300_RB3D_EARLY_Z (0x4F14)
+ if depth test is not enabled it should be R300_EARLY_Z_DISABLE
+ if depth is enabled and alpha not it should be R300_EARLY_Z_ENABLE
+ if depth and alpha is enabled it should be R300_EARLY_Z_DISABLE
*/
r300ContextPtr r300 = R300_CONTEXT(ctx);
R300_STATECHANGE(r300, unk4F10);
if (ctx->Color.AlphaEnabled && ctx->Color.AlphaFunc != GL_ALWAYS)
/* disable early Z */
- r300->hw.unk4F10.cmd[2] = 0x;
+ r300->hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
else {
if (ctx->Depth.Test && ctx->Depth.Func != GL_NEVER)
/* enable early Z */
- r300->hw.unk4F10.cmd[2] = 0x0001;
+ r300->hw.unk4F10.cmd[2] = R300_EARLY_Z_ENABLE;
else
/* disable early Z */
- r300->hw.unk4F10.cmd[2] = 0x;
+ r300->hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
}
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] R300 early Z cleanup
Attached is a mini-patch to add the address of early Z to r300_reg.h and
use it.
Jerome Glisse helped me with this patch. Thanks. :-)
diff --git a/src/mesa/drivers/dri/r300/r300_reg.h b/src/mesa/drivers/dri/r300/r300_reg.h
index 9f636ec..5dfd1fb 100644
--- a/src/mesa/drivers/dri/r300/r300_reg.h
+++ b/src/mesa/drivers/dri/r300/r300_reg.h
@@ -1378,6 +1378,10 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
/* 16 bit format or some aditional bit ? */
# define R300_DEPTH_FORMAT_UNK32 (32 << 0)
+#define R300_RB3D_EARLY_Z 0x4F14
+# define R300_EARLY_Z_DISABLE 0
+# define R300_EARLY_Z_ENABLE 1
+
/* gap */
#define R300_RB3D_DEPTHOFFSET 0x4F20
diff --git a/src/mesa/drivers/dri/r300/r300_state.c b/src/mesa/drivers/dri/r300/r300_state.c
index b30ece1..0e33e51 100644
--- a/src/mesa/drivers/dri/r300/r300_state.c
+++ b/src/mesa/drivers/dri/r300/r300_state.c
@@ -328,24 +328,24 @@ static void r300UpdateCulling(GLcontext* ctx)
static void update_early_z(GLcontext *ctx)
{
- /* updates register 0x4f14
- if depth test is not enabled it should be 0x
- if depth is enabled and alpha not it should be 0x0001
- if depth and alpha is enabled it should be 0x
+ /* updates register R300_RB3D_EARLY_Z (0x4F14)
+ if depth test is not enabled it should be R300_EARLY_Z_DISABLE
+ if depth is enabled and alpha not it should be R300_EARLY_Z_ENABLE
+ if depth and alpha is enabled it should be R300_EARLY_Z_DISABLE
*/
r300ContextPtr r300 = R300_CONTEXT(ctx);
R300_STATECHANGE(r300, unk4F10);
if (ctx->Color.AlphaEnabled && ctx->Color.AlphaFunc != GL_ALWAYS)
/* disable early Z */
- r300->hw.unk4F10.cmd[2] = 0x;
+ r300->hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
else {
if (ctx->Depth.Test && ctx->Depth.Func != GL_NEVER)
/* enable early Z */
- r300->hw.unk4F10.cmd[2] = 0x0001;
+ r300->hw.unk4F10.cmd[2] = R300_EARLY_Z_ENABLE;
else
/* disable early Z */
- r300->hw.unk4F10.cmd[2] = 0x;
+ r300->hw.unk4F10.cmd[2] = R300_EARLY_Z_DISABLE;
}
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
Am Mittwoch, den 10.01.2007, 15:54 +0100 schrieb Paul Heldens: > http://dri.freedesktop.org/wiki/R300_20Portal I think it's a good idea but it's really hidden. And lacks content ... a bit ;-) But it's a good start. I'm willing to fill it with more information... is it available in an "aggregated" form, or do I have to gather things from watch git? What about a monthly "Git changes for R300" on that page? Regards, Christoph - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r500 - where to start?
> Might it be an idea to collect these tools on a single page? Definitely! So I hacked it up at: http://dri.freedesktop.org/wiki/ReverseEngineering Maybe everything is wrong. Maybe it helps. I have no idea. I never used with any of these. Regards, Christoph Brill - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 code cleanup
Am Dienstag, den 04.07.2006, 18:35 +0200 schrieb Jerome Glisse: > On 7/4/06, Tilman Sauerbeck <[EMAIL PROTECTED]> wrote: > > Jerome Glisse [2006-07-03 23:49]: > > > For indenting rules i personnaly use the linux kernel ones, > > > iirc this was the original indenting choosed by Nicolai. > > > Anyway, we can use another if people prefer another one > > > (as long as the indenting you propose is not severly broken). > > > > Shouldn't we stick to the Mesa indentation rules? > > http://www.mesa3d.org/devinfo.html > > You could find rules for Mesa there, duno if there are the actual > one :) If no one object i will go with this one. > > > > For function name i think that r300DoSomething is for > > > function called by mesa and r300_do_otherthings is for > > > internal driver function at leat this is my guess from looking > > > at i915 driver :) > > > > I'd prefer not to mix up CamelCase and snake_case. Do you think the > > benefit it provides is good enough to make up for the inconsistency? > > I think this is good enough, thus you can easily spot which function > are called by mesa and which one could only be called inside the > driver. There is little explanation for that here : > http://www.mesa3d.org/devinfo.html > > Btw what about doxygen comment ? Might help people looking at > the driver and might help refreshing memory when you get back > on old code :) I personally dislike using doxygen. It bloats the code without having a real benefint. Most developers don't comment oder don't comment very well. Without a "Guide on documenting code" it's pretty useless from my experience. And I think especially in hardware development (when you're happy when you are done ;-) ) the "special tricks necessary to get it working" will in best cases be found in a normal comment and not the Doxygen one. But I like doxygen to create call graphs. This is pretty helpfull whe I try to trace function calls to understand what is happening (like pressing F3 in Eclipse when developing Java). But I really recommend documenting the code in whatever way is the best :-) Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Lockups
Jerome Glisse schrieb: In the meantime, if you use lastet Benh patch and set agp speed to 1 and no fastwrite or other fency options you should have something a bit more stable at least which doesn't lockup in the minute... Will give it a try if one points me out where to get the patch. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Lockups
Aapo Tahkola schrieb: On Thu, 02 Mar 2006 09:27:37 +0100 Christoph Brill <[EMAIL PROTECTED]> wrote: Hi list, I'm still seeing lots of lockups with my r300 (Radeon 9700Pro) with current drm/mesa/xf86-video-ati cvs. I think I found a reproducable lockup. It happens when I use Wings3d[1] (a free modeller). Wings has a grid for orientation when I move around the camera it works fine. But as soon as the grid hits the borders of the window, my system locks up. I'm not 100% sure so if anyone else can reproduce this it would be great. As long as it gets solved by initializing the card with fglrx, I don't see any point in investigating. Does it lock only if you hit upper or lower bound of screen? I haven't tested it with initializing fglrx first. Will do tonight. The lockup happens when it hits the lower border. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Lockups
Hi list, I'm still seeing lots of lockups with my r300 (Radeon 9700Pro) with current drm/mesa/xf86-video-ati cvs. I think I found a reproducable lockup. It happens when I use Wings3d[1] (a free modeller). Wings has a grid for orientation when I move around the camera it works fine. But as soon as the grid hits the borders of the window, my system locks up. I'm not 100% sure so if anyone else can reproduce this it would be great. Thanks, Christoph Brill [1] http://www.wings3d.com --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRI snapshots built from modular Xorg
Felix Kühling wrote: Hi, I just uploaded the first set of snapshots built from the modular Xorg tree (20060226). This now has the latest and greatest changes in Xorg CVS that the monolithic tree did not have. Among other things this means that i915 should now work again, with rotation support. It also has Benjamin Herrenschmidt's memory mapping changes that should solve lockup problems on many Radeons. Please let me know if there are any new problems with installing these snapshots. Regards, Felix Thanks for the work! BTW: Someone should redirect www.freedesktop.org/*dri*/*snapshots*/ to http://dri.freedesktop.org/snapshots/ ... it's listed first on google when search for "dri snapshot" and it's quite dead :) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
