Re: RFC: xfree: dri2: libdrm as optional
On Tue, 2010-01-19 at 20:18 +0100, Vignatti Tiago (Nokia-D/Helsinki)
wrote:
Some drivers use DRI2 protocol but implement their own kernel rendering
mananger. For these drivers, libdrm becomes useless.
The only inconvenient right now to put libdrm optional to X server is
concerning DRI2Authenticate. Such function uses drm_magic_t and drmAuthMagic
symbols from libdrm. So I thought two alternatives.
1. wrap with some macros and set at compilation time:
#ifndef WITH_DRM
typedef unsigned int drm_magic_t;
#endif
Bool
DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic)
{
#ifdef WITH_DRM
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
if (ds == NULL || drmAuthMagic(ds-fd, magic))
return FALSE;
return TRUE;
#else
return FALSE;
#endif
}
2. hide all trickery inside xorg driver, adding a new field to DRI2InfoRec:
Bool
DRI2Authenticate(ScreenPtr pScreen, unsigned int magic)
{
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
if (ds == NULL || (*ds-AuthMagic)(ds-fd, magic))
return FALSE;
return TRUE;
}
In the first alternative the implementation is straightforward but should be
adjusted at build time. It's ugly. Also, one would want to implement his own
way of clients authentication, or not (sigh) - note though dri2proto states
that this is not mandatory:
A kernel rendering manager can choose not to implement any
authentication and just allow access to all buffers.
Alternative 2. seems more complete but requires code changes all over the
drivers. I'm more inclined for this alternative... Moreover, for both
alternatives we need to do something with drm_magic_t type - can we just use
unsigned int instead declare such new type?
Does it really matter that we would leave the drm_magic_t typedef
defined? In this case, we would just have one ifdef inside
DRI2Authenticate().
But I agree, moving the auth checking into a function in DRI2InfoRec
might be the nicest solution but harder to get in considering it touches
all the drivers.
So what you guys think about this all?
Thanks,
Tiago
___
xorg-devel mailing list
xorg-de...@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 line width problem
Hi, I accidentally used |= instead of =. I'll push the fix now. Thanks for reporting the bug. :) On 6/21/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi everybody. I think that http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=da1d9d97959bd1e4c8e359d28b4fd6cafdd4168a broke line widths for r300. If I change the width to 3.0 for example and the back to 1.0 all lines are renderer with width 3.0. Regards Papadakos Panagiotis - 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 - 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: R300 line width problem
Done. Took a little longer because I had to clone a clean tree so I could push the patch... I have a lot of changes in my local Mesa that are not quite ready to be pushed yet. On 6/21/07, Oliver McFadden [EMAIL PROTECTED] wrote: Hi, I accidentally used |= instead of =. I'll push the fix now. Thanks for reporting the bug. :) On 6/21/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi everybody. I think that http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=da1d9d97959bd1e4c8e359d28b4fd6cafdd4168a broke line widths for r300. If I change the width to 3.0 for example and the back to 1.0 all lines are renderer with width 3.0. Regards Papadakos Panagiotis - 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 - 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: r300 texture rendering corruption
This looks like DTX or S3TC texture compression (which is partially broken); I think there should be some more information on this on the list, and how to disable it. On 6/12/07, Mikko Rauhala [EMAIL PROTECTED] wrote: ti, 2007-06-12 kello 02:26 +, Oliver McFadden kirjoitti: I couldn't reproduce this with the latest Git of Mesa and DRM. Although R300 does have some lockup problems that get triggered after running UT2004 for a while... I think it does crash sometimes, but not very often. Which is nice. Actually the free 3D programs I find in Ubuntu crash the r300 driver fairly more often... Oh, it seems I forgot to mention I'm on AMD64 (and running the AMD64 version of UT2k4). Silly me. Try again using the latest Mesa and DRM from Git, and let me know if the texture corruption problem still exists. Maybe I was being a bit unclear. The textures as such are not corrupted, they're just rendered in a somehow corrupt fashion. The location of the corruption also changes. See http://mjr.iki.fi/ut2004/ for some sample screenshots of Arctic Stronghold. I took them using the current git (master branch) libdrm and mesa (libGL friends plus r300_dri.so). One of them shows the mostly ok snow (some blue artifacts...) and rock, while others concentrate on the highly problematic bases. To be sure I got it right, this is how I tried the git driver version (/opt/drm is where I stashed the git libdrm after compilation): export LIBGL_DRIVERS_PATH=/home/mjr/src/git/mesa/lib64 export LD_LIBRARY_PATH=/opt/drm/lib:/home/mjr/src/git/mesa/lib64 ./ut2004 I'll be co-operative if there's something further to try; thanks :) -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ - 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 - 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: Figuring out R300_VAP_CNTL
I think this register is the same on mobility and standard chips. I still haven't figured it out yet, although airlied gave me a few pointers about it. I think that unless we can find some way to make the blob change it, it might not be possible to determine what it does... On 5/28/07, Martijn de Nerd [EMAIL PROTECTED] wrote: Hi, I have no clue what VAP_CNTL is, nor do I know what a vertex shader engine is, but damn, since i read about its existance I can't wait to use mine! So attached is the output of my mobility radeon. Goodluck! Martijn - 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
Figuring out R300_VAP_CNTL
Hi, I was talking to airlied on #dri-devel about figuring out the R300_VAP_CNTL (0x2080) register. He explained that it controls the vertex shader engine, but other than that we don't really know. This register could be card dependent, so I modified radeontool to dump it, and I'm posting here asking for dumps. :) So, for anyone who wants to make a dump, do the following WHEN RUNNING FGLRX; we already know what our driver does. :) git clone git://people.freedesktop.org/~z3ro/radeontool cd radeontool/ make sudo lspci -vvv mail.txt sudo ./radeontool regs mail.txt Then please reply with mail.txt attached. I only need the Radeon part of lspci, so you could remove the rest if you like. Thanks. - 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
My thoughts are, we should unify the really common stuff... but I don't think it's possible to unify r200_tex.c and r300_tex.c. The hardware is different, and the file would end up with an #ifdef on every 3rd line; it doesn't make sense here. Just for really common code it does. I don't know what is going to happen with TTM. Maybe we should hack the r300 driver for TTM (and someone else can do R200 and R128 (radeon) if they like) or maybe we should start a new DRI driver completely from scratch, with TTM and good state handling in mind from the beginning. Then we just take the code we need from R300 and merge it into the new DRI driver. Regarding indenting, I indented the driver with the Linux kernel style because that is what matched most (but not all) of the code. The indenting was a little inconsistent. If you like, fell free indent the R200 or R128 (radeon) code, too. I guess for TTM we'll have to wait and see what happens... On 5/14/07, Jerome Glisse [EMAIL PROTECTED] wrote: On 5/14/07, Christoph Brill [EMAIL PROTECTED] wrote: 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. If you want to reunify some more function i think you should stick to radeon indentation as you won't likely rewrite most of it, so better follow its code guideline. That said i have the feeling that if we ever want to have ttm on radeon (and i believe we do :)) we will some times need to rewrite most of it at least i did have the impression that most others dev thought that. best, Jerome Glisse - 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 - 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
A few R300 questions
Hi, I have a few questions about the R300 driver. I'm just wondering about a couple of things including the OPTIMIZE_ELTS code (r300_render.c) and R300_VAP_INPUT_ROUTE_0_0 and R300_VAP_INPUT_ROUTE_1_0. I cleaned up the OPTIMIZE_ELTS code to reduce duplication, and I verified that both the optimized and non-optimized code works with Quake 3 Arena, however, I'm not exactly sure how this optimization works or what it's purpose is? The other question is regarding R300_VAP_INPUT_ROUTE_0_0 and R300_VAP_INPUT_ROUTE_1_0. The values for these registers are constructed in r300_emit.c with the functions t_vir0 and t_vir1, respectively, but I haven't figured these functions out yet. Lots of bitwise operations. I can go through this and figure it out, but if someone else already knows and can explain it that would certainly be helpful. :) I need to understand and extend these functions because r300_ioctl.c:r300EmitClearState writes hard-coded values to these registers, and this should be replaced with calls to (extended) t_vir0 and t_vir1. These probably need to be renamed, too. Thank you. - 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: offtopic: ati oss news
Talk is cheap. Show me the code. Or in our case, specs... I'll get excited then. Until they do that this is just ATI making wild claims. On 5/11/07, Jacek Poplawski [EMAIL PROTECTED] wrote: http://www.0xdeadbeef.com/weblog/?p=288 Probably nobody knows what does it mean, but maybe it's a good news :) -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net - 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: R300 cleanup questions
Hi,
I added the not implemented yet comment back, although there are other places
that use 65535 so it could be some kind of hardware limit...
The only reason that I went with camel case r300FooBar names is because that's
what 90% of the driver uses; it's easier to change a few r300_foo_bar to
r300FooBar than the other way around. The important thing is it's consistent.
Now I just hope I don't get shot for all the commits. ;)
On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 5/8/07, Christoph Brill [EMAIL PROTECTED] wrote:
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?
I think it's better to have static function, i am thinking of symbol
export and
other things like that.
Yes, make functions static whenever possible.
-/* 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?
We can use the one we like, i prefer r300_foo_bar over r300FooBar which
i dislike but the choice is up to the first person who do big cleanup :)
and
we do not have to conform to mesa coding style for driver but use the one
we like the more.
Yes, core Mesa has a fairly consistant naming scheme but it's the
prerogative of the driver writers to choose their style. That said,
naming within each driver should be consistant.
-Brian
-
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
-
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: R300 cleanup questions
I also think we might need to add _dri_warning/_dri_error because the _mesa
versions output Mesa warning: %s which implies to the user this is a Mesa
problem, not a DRI driver problem.
I could add r300Warning and r300Error, but probably all DRI drivers need warning
and error functions... So maybe adding them to the common DRI code?
On 5/9/07, Oliver McFadden [EMAIL PROTECTED] wrote:
Hi,
I added the not implemented yet comment back, although there are other
places
that use 65535 so it could be some kind of hardware limit...
The only reason that I went with camel case r300FooBar names is because
that's
what 90% of the driver uses; it's easier to change a few r300_foo_bar to
r300FooBar than the other way around. The important thing is it's
consistent.
Now I just hope I don't get shot for all the commits. ;)
On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 5/8/07, Christoph Brill [EMAIL PROTECTED] wrote:
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?
I think it's better to have static function, i am thinking of symbol
export and
other things like that.
Yes, make functions static whenever possible.
-/* 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?
We can use the one we like, i prefer r300_foo_bar over r300FooBar which
i dislike but the choice is up to the first person who do big cleanup :)
and
we do not have to conform to mesa coding style for driver but use the
one
we like the more.
Yes, core Mesa has a fairly consistant naming scheme but it's the
prerogative of the driver writers to choose their style. That said,
naming within each driver should be consistant.
-Brian
-
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
-
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: R300 cleanup questions
I'd like some input on the VBO stuff in r300. In r300_context.h we have the
following.
/* KW: Disable this code. Driver should hook into vbo module
* directly, see i965 driver for example.
*/
/* #define RADEON_VTXFMT_A */
#ifdef RADEON_VTXFMT_A
#define HW_VBOS
#endif
So the VTXFMT (radeon_vtxfmt_a.c) code is disabled anyway. This also disables
hardware VBOs. I guess this has been done since the new VBO branch was merged.
So, the question is, should this dead code be removed? I think all drivers are
(or should be) moving to the new VBO code anyway.
I've already made a patch for this, but I'm not committing until I get the okay
from a few people.
Thanks.
On 5/9/07, Oliver McFadden [EMAIL PROTECTED] wrote:
I also think we might need to add _dri_warning/_dri_error because the _mesa
versions output Mesa warning: %s which implies to the user this is a Mesa
problem, not a DRI driver problem.
I could add r300Warning and r300Error, but probably all DRI drivers need
warning
and error functions... So maybe adding them to the common DRI code?
On 5/9/07, Oliver McFadden [EMAIL PROTECTED] wrote:
Hi,
I added the not implemented yet comment back, although there are other
places
that use 65535 so it could be some kind of hardware limit...
The only reason that I went with camel case r300FooBar names is because
that's
what 90% of the driver uses; it's easier to change a few r300_foo_bar to
r300FooBar than the other way around. The important thing is it's
consistent.
Now I just hope I don't get shot for all the commits. ;)
On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 5/8/07, Christoph Brill [EMAIL PROTECTED] wrote:
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?
I think it's better to have static function, i am thinking of symbol
export and
other things like that.
Yes, make functions static whenever possible.
-/* 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?
We can use the one we like, i prefer r300_foo_bar over r300FooBar
which
i dislike but the choice is up to the first person who do big cleanup
:)
and
we do not have to conform to mesa coding style for driver but use the
one
we like the more.
Yes, core Mesa has a fairly consistant naming scheme but it's the
prerogative of the driver writers to choose their style. That said,
naming within each driver should be consistant.
-Brian
-
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
-
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: R300 cleanup questions
Here is the patch.
On 5/9/07, Oliver McFadden [EMAIL PROTECTED] wrote:
I'd like some input on the VBO stuff in r300. In r300_context.h we have the
following.
/* KW: Disable this code. Driver should hook into vbo module
* directly, see i965 driver for example.
*/
/* #define RADEON_VTXFMT_A */
#ifdef RADEON_VTXFMT_A
#define HW_VBOS
#endif
So the VTXFMT (radeon_vtxfmt_a.c) code is disabled anyway. This also
disables
hardware VBOs. I guess this has been done since the new VBO branch was
merged.
So, the question is, should this dead code be removed? I think all drivers
are
(or should be) moving to the new VBO code anyway.
I've already made a patch for this, but I'm not committing until I get the
okay
from a few people.
Thanks.
On 5/9/07, Oliver McFadden [EMAIL PROTECTED] wrote:
I also think we might need to add _dri_warning/_dri_error because the
_mesa
versions output Mesa warning: %s which implies to the user this is a
Mesa
problem, not a DRI driver problem.
I could add r300Warning and r300Error, but probably all DRI drivers need
warning
and error functions... So maybe adding them to the common DRI code?
On 5/9/07, Oliver McFadden [EMAIL PROTECTED] wrote:
Hi,
I added the not implemented yet comment back, although there are other
places
that use 65535 so it could be some kind of hardware limit...
The only reason that I went with camel case r300FooBar names is
because
that's
what 90% of the driver uses; it's easier to change a few r300_foo_bar to
r300FooBar than the other way around. The important thing is it's
consistent.
Now I just hope I don't get shot for all the commits. ;)
On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 5/8/07, Christoph Brill [EMAIL PROTECTED] wrote:
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?
I think it's better to have static function, i am thinking of symbol
export and
other things like that.
Yes, make functions static whenever possible.
-/* 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?
We can use the one we like, i prefer r300_foo_bar over r300FooBar
which
i dislike but the choice is up to the first person who do big
cleanup
:)
and
we do not have to conform to mesa coding style for driver but use
the
one
we like the more.
Yes, core Mesa has a fairly consistant naming scheme but it's the
prerogative of the driver writers to choose their style. That said,
naming within each driver should be consistant.
-Brian
-
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
From 89e03351b354231117240f34bf7cc48c76a3e99b Mon Sep 17 00:00:00 2001
From: Oliver McFadden [EMAIL PROTECTED]
Date: Wed, 9 May 2007 15:50:11 +
Subject: [PATCH] r300: Removed the deprecated VTXFMT code.
---
src/mesa/drivers/dri/r300/Makefile |1 -
src/mesa/drivers/dri/r300/r300_context.c| 10 +-
src/mesa/drivers/dri/r300/r300_context.h| 19 -
src/mesa/drivers/dri/r300/r300_ioctl.c |8 -
src/mesa/drivers/dri/r300/r300_maos.c | 26 -
src/mesa/drivers/dri/r300/r300_render.c | 44 ++
src/mesa/drivers/dri/r300/r300_state.c |4 -
src/mesa/drivers/dri/r300/radeon_vtxfmt_a.c | 662 ---
8 files changed, 45 insertions(+), 729 deletions(-)
delete mode 100644 src/mesa/drivers/dri/r300/radeon_vtxfmt_a.c
diff --git a/src/mesa/drivers/dri/r300/Makefile
b/src/mesa/drivers/dri/r300/Makefile
index 65a6b03
Re: R300 cleanup questions
Well both Keith and Jerome are okay with me removing the VTXFMT code, so I'll go ahead and do that. I don't think there is any serious risk as I'm only removing code that is already disabled. :) Brian, let me know if you want to make a branch so I know when I can push. On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote: Oliver McFadden wrote: I also think we might need to add _dri_warning/_dri_error because the _mesa versions output Mesa warning: %s which implies to the user this is a Mesa problem, not a DRI driver problem. I could add r300Warning and r300Error, but probably all DRI drivers need warning and error functions... So maybe adding them to the common DRI code? You could just stick with _mesa_warning() and prefix the messages with R300. -Brian - 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: R300 cleanup questions
Done. On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote: If it's just dead code removal, go ahead. -Brian Oliver McFadden wrote: Well both Keith and Jerome are okay with me removing the VTXFMT code, so I'll go ahead and do that. I don't think there is any serious risk as I'm only removing code that is already disabled. :) Brian, let me know if you want to make a branch so I know when I can push. On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote: Oliver McFadden wrote: I also think we might need to add _dri_warning/_dri_error because the _mesa versions output Mesa warning: %s which implies to the user this is a Mesa problem, not a DRI driver problem. I could add r300Warning and r300Error, but probably all DRI drivers need warning and error functions... So maybe adding them to the common DRI code? You could just stick with _mesa_warning() and prefix the messages with R300. -Brian - 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: GARTSize option not documented on radeon and other problems
On 5/4/07, Jerome Glisse [EMAIL PROTECTED] wrote: There was a typo in my mail, i meaned lock not lockup when i was talking about apps sending data to gpu. And if multiple instance of glxgears are successfull to make the gpulockup this is because you are then sending megs of vertex to the card and this has a highmemory bandwith usage which trigger the lockup, at leat i believe lockup happen because of that, sometimes it's only a soft lockup only the gpu die but sometimes the gpu take down with him the pci bus and you got a hard lockup. best, Jerome Glisse I'm wondering if this is some timing initialization issue. I might try to check this out with airlied's radeontool. I think this is the current theory as to why it happens. - 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: GARTSize option not documented on radeon and other problems
On 5/3/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, sorry for the crossposting, I don't know who to address. I am experimenting the new CFS scheduler on Linux and tried to start multiple glxgears to see whether they are really running smooth and have evenly distributed framerate. At first I could only start two instances of glxgears but the third didn't start saying that it cannot allocate GART memory and try to increase increase GARTSize. First problem: man radeon doesn't have anything about this option, although radeon_drv.so contains this keyword. I tried guessing whether the parameter is in MBs and have set it to 128 but it disabled DRI because of some out of memory condition. Setting it to 64 gave me working DRI and I am able to start up some more instances of glxgears. Second problem: if I start 16 of them, the last 3 behaves very strange, i.e. instead of the spinning gears I get chaotic flickering triangles. As soon as the number of glxgears goes down to 13 every window behaves normal. Third problem: starting up 32 glxgears locked up the machine almost instantly but having only 16 of them also locks up the machine after some time passed. The machine is x86-64, Athlon64 X2 4200, PCIe Radeon X700 with 128MB onboard memory, up-to-date Fedora Core 6. Best regards, Zoltán Böszörményi This is interesting. I've occasionally seen my engine just display a mess of triangles, but if I was to kill it and start it again, it would work fine. This only happened very occasionally so I could never track down the problem. If running more than 13 glxgears shows the problem then maybe it would have a chance of getting fixed. :) You might want to open a bug report on the Freedesktop Bugzilla. The lockups are nothing new, unfortionally. I think there is a bug somewhere in the R300 driver. You can also get deadlocks which are a little different... I think that these might go away after R300 uses TTM and thus doesn't grab the hardware lock anymore for texture upload, etc. - 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: Possible R300 Issues
I just updated the tool to (hopefully) calculate the AGP aperture address and size dynamically. I'm using some code borrowed from REnouveau. I haven't tested this yet, but it should work. Again, if anyone is using this I'd like to get feedback on what features would be useful. Currently I plan to implement a way to diff between separate runs so that you could diff between R300 and R500, for example. Also, I'm not sure if I should separate this tool into a dumper and parser, or keep them together as one program. I think that I will just internally split it. The dumping code would build a list of commands it finds along with other information, and the parsing part would interpret that list and allow for better analysis... On 4/26/07, Dave Airlie [EMAIL PROTECTED] wrote: Dave, how did you generate this file? (Was it from an indirect buffer?) http://www.skynet.ie/~airlied/dri/mypa.parsed Magic and guess work produced that file... Basically I used glxtest which works fine to dump the maps just actually finding the IB is a lot more impossible.. I search for 10a4 which is usually the start of a packet in the map*.* files and figured it out from there, usually 10a4 appeared in map4 for me and I just hacked around until the preety print produced something useful... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - 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: Possible R300 Issues
On 4/26/07, Phillip Ezolt [EMAIL PROTECTED] wrote:
Oliver Dave,
You maybe have missed out on #dri-devel on freenode irc, it works
reasonably well for getting insta-answers depending on timezone etc..
Ah. I HAVE missed that. I'll have to hang out there. I usually have
the wireless network turned off when I'm X hacking, but this gives me
a reason to fix that.
Dave eventually got the RS480 working, (which is great, but
frustrating that I couldn't have the rush... ;-) )
Hey 3D is still busted on the rs480, I've no idea when I'll get around to
it, I'm sorta tipping away and the internals of r300 are not the nicest
place to hack around in..
Alright. I've been playing with trying to get simple triangles to
work with my 200M.
(I've set hw_tcl to 0, and things still don't work properly.)
My biggest obstacle is getting blob dumps that I can compare to what X
is currently doing.
I've tried revenge, but I am getting bogus results. I'm pretty sure
that the problem is that I don't have the AGP apeture variable set
properly. Oliver, what does that value represent?
Currently this is hard-coded, because I haven't done dynamic calculation of
those variables yet.
You can determine REG_ADDR from lspci -v; you want the line that matches
(32-bit, non-prefetchable) [size=64K]. In the following example, REG_ADDR
would be 0xe500. I haven't figured out how to calculate REG_SIZE yet; It's
just copied from IBA.
02:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP
[Radeon 9600] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc RV350 AP [Radeon 9600]
Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 16
Memory at c000 (32-bit, prefetchable) [size=256M]
I/O ports at c000 [size=256]
Memory at e500 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at e400 [disabled] [size=128K]
Capabilities: [58] AGP version 3.0
Capabilities: [50] Power Management version 2
You can determine AGP_ADDR and AGP_SIZE from dmesg | grep 'AGP aperture'.
agpgart: AGP aperture is 64M @ 0xe000
Is it the physical address of the ring buffer? In a system where the
ring buffer lives in GART addressible memory, wouldn't you basically
need to reimplement the GART in software? (Because there is no single
address range which represents the entire ring buffer... It is a
series of pages...) If the ring buffer lives in the framebuffer,
things are much easier..
...
Also, I've tried glxtest, but the indirect buffer has NO match in the
maps.log file.
Dave, how did you generate this file? (Was it from an indirect buffer?)
http://www.skynet.ie/~airlied/dri/mypa.parsed
That appears to be a dump of an indirect buffer, parsed with
pretty_print_command_stream.tcl. Currently that program is able to parse the
indirect buffers better than my tool, as it can print register names in human
readable format, but this is a high priority on my TODO list too.
If you want to use pretty_print_command_stream.tcl you must feed it the indirect
buffer in hexadecimal format, one value per line, with no 0x prefix.
deadbeef
deadbeef
deadbeef
...
If you want revenge to dump in this format, you would have to modify
analyze.c:analyze_indirect_buffer.
Change the following line.
analyze_packets (0, ib_size, ib_mapped_addr);
To.
int i;
for (i = 0; i ib_size; i++)
{
printf (%80lx\n, ib_mapped_addr[i]);
}
I downloaded glxtest from sourceforge/r300. Is there a more updated
version that works?
It should work, but a lot of the R300 tools are very hard-coded, so sometimes
they require some work. I hope that my tool will become a lot easier to use and
more dynamic.
I do have more work to do on it, though. I'd like to hear feedback, too. :) Any
wanted features, bugs, annoyances, etc.
-
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: Possible R300 Issues
On 4/23/07, Phillip Ezolt [EMAIL PROTECTED] wrote: Oliver, I've been hacking on the RS480 (Radeon 200M) for a while, and Dave has (aweseomely) brought it to a point where it has the working GART, and a limping Mesa. Currently triangles are broken, and I have a very simple test case (the depth example) which demonstrates the problem. I want to fix that. I would like to use your tool (revenge) to compare the binary blob with the current Mesa. How do I use it? I've checked it out, but the README is empty. Do you have any docs/examples? (Even a typescript of you running it a few times would help) Cheers, --Phil I haven't written a README yet because it's still very experimental. Actually I do have a draft README I should clean up... You should just be able to start an X server and run ./revenge, after the usual ./configure make. You will need to be root or setup setuid for revenge as it needs access to /dev/mem. It will print the information to stdout. # startx # ./revenge All it does is look at the ring head/tail before executing some GL commands (usually drawing a triangle) and checks the ring head/tail again afterwards. It then does and analyses the packets that were added to find out the register writes. It does not display the register names in a human readable format yet so you must instead use: grep -i 'f00' radeon_reg.h r300_reg.h. I plan to add rules-ng support and convert the header files into an XML database so that the register names can be printed in human readable format. I also don't analyze the indirect buffer's yet, but this should be trivial to add; it just needs some different shifts/masks on the packets. For now, you can use pretty_print_command_stream.tcl from glxtest (see DRI wiki) to print the indirect buffers, and it can (to a limited extent) display in human readable format. I also have to add support for disassembling fragment and vertex programs intelligently. So there is quite a bit of work still left to do before it's especially useful; you can use it now, but some manual work is required. I would appreciate any feedback from you, and I also don't mind answering other questions. :) You can see a (old) example of the output at http://z3ro.name/tmp/revenge_null_tri.diff. - 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: Possible R300 Issues
On 4/23/07, Phillip Ezolt [EMAIL PROTECTED] wrote: Awesome. As an aside, I would really like to make it easier for other people to hack on radeon X. I've been fighting with my Radeon 200M for months, hacking when I have spare time. I think we have similar goals here. I'm doing this to hopefully make reverse engineering a bit easier, and also to improve my knowledge of Radeon and R300. I haven't yet tried my tool on R500 or above because I don't have an R500 card yet... I'll probably end up waiting for the work that Jerome Glisse et al are doing on R500 to become public. I think my tool should work there, too. I just started reading the X code about 6 months ago, and the learning curve has been steep. My emails to dri-devel are answered now and again, and that is kinda frustrating when you want an answer NOW. Dave eventually got the RS480 working, (which is great, but frustrating that I couldn't have the rush... ;-) ) Heh. That's always fun. :) Anyway, I've been thinking about documenting what I've learning (so that it is easier for other people.) Here are my ideas for topics: 0) How the radeon card is laid out. 1) Document how the radeon chipset works. (At least as much as I know..) 2) Document how DRM/DRI/X actually interacts with this. 3) How to troubleshoot a problem. (Such as reverse engineering the GART) 4) A reverse engineering stragegy for radeon people. If I slap something up, would you mind looking it over/fixing/correcting it? Absolutely. I'm not an expert, but I can do my best. :) I'm sure that I could get some of the more experienced people to look over it, too. I guess this should probably be done on the Freedesktop Wiki. I could help on the ring buffer and indirect buffer packet format; I think I have a pretty good handle on this now. I intend to look into the vert/frag prog stuff, too, but I haven't done this yet. Cheers, --Phil Example: ./bitfield ati_regs.example I think that rules-ng is a better solution for me anyway. You can read about it at http://nouveau.cvs.sourceforge.net/nouveau/rules-ng/. I just have to integrate it into my tool. Pekka Paalanen already modified mmio-parse to add support for rules-ng, so I'll probably look at this for ideas. By the way, you should probably CC dri-devel too. I'm forwarding my replies dri-devel but you're just sending your emails directly to me. - 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: Possible R300 Issues
On 4/23/07, Dave Airlie [EMAIL PROTECTED] wrote: I just started reading the X code about 6 months ago, and the learning curve has been steep. My emails to dri-devel are answered now and again, and that is kinda frustrating when you want an answer NOW. You maybe have missed out on #dri-devel on freenode irc, it works reasonably well for getting insta-answers depending on timezone etc.. Dave eventually got the RS480 working, (which is great, but frustrating that I couldn't have the rush... ;-) ) Hey 3D is still busted on the rs480, I've no idea when I'll get around to it, I'm sorta tipping away and the internals of r300 are not the nicest place to hack around in.. Yeah, a clean up would probably be a very good idea for the R300 driver. But this is tricky because it takes a lot of time to clean up code, and make sure you didn't accidentally break something... Maybe we can try comparing the ring and indirect buffer writes from the blob for R300 vs RS480. Just drawing a simple triangle. I'll probably try to add some more advanced analysis code into my tool soon. I'm thinking of a list like: int count; int type, reg, val; So the tool just builds the list at run-time then does the real analysis after it's executed and created lists for each of the GL tests. This way I could do a semi-intelligent diff between the different tests. Add functionality for reading/writing the list as a binary file and we can then do comparison between different hardware. Just an idea for the moment. I haven't worked out the details yet. Oh, I also just added indirect buffer analysis to my tool. It's still pretty primitive and I need to remove some duplicate code, but it's progressing. :) - 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
Possible R300 Issues
I've previously filed a bug report (bug #10211) about the R300_RB3D_DSTCACHE_CTLSTAT issue, however I couldn't prove the proposed patch was correct. I've investigated this further and I can confirm that the blob indeed writes 0xa to R300_RB3D_DSTCACHE_CTLSTAT before 3D operations, and 0x2 after 3D operations. I've also found some other issues that should probably be fixed, although they are not critical. When drawing a simple triangle the blob produces a few type 1 packets, and an indirect buffer. The indirect buffer contains all of the main 3D commands. It should also be noted that the blob performs the writes to R300_RB3D_DSTCACHE_CTLSTAT inside the indirect buffer, while our driver does not. The blob then resets R300_RB3D_DSTCACHE_CTLSTAT to 0x0 after the indirect buffer, again, our driver doesn't do this. When drawing a simple triangle our driver produces mostly type 1 packets, and a few type 3 packets I've yet to decode. Our driver does not use an indirect buffer. So, I think that some improvement is required. Specifically: 1. Use indirect buffers in the same way the blob does, even for simple things like a single triangle. 2. Move the R300_RB3D_DSTCACHE_CTLSTAT writes (0xa/0x2) to the start and end of the indirect buffer. 3. Add a type 1 packet after the indirect buffer to reset R300_RB3D_DSTCACHE_CTLSTAT to 0x0. 4. Compare our drivers output with the blob again, and look into any other differences. I realize there will be some differences, but currently even drawing a simple triangle seems to be radically different. This probably won't help with lockups, but I think we should try and minimize the differences between what our driver outputs and what the blob outputs. We should try to match the blob as closely as possible, because this will make finding bugs a lot easier. I've already been able to confirm the R300_RB3D_DSTCACHE_CTLSTAT issue using my tool: http://gitweb.freedesktop.org/?p=users/z3ro/revenge.git;a=summary While this particular case is not a serious issue, I am convinced that serious issues exist in our driver, and are possibly the reason(s) for the lockups. I would be willing to work on this if someone can give me some pointers about where our driver does indirect buffer submission, etc. Basically the path of drawing a simple triangle. I'd also like to hear some other people's thoughts on this... - 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: [PATCH] [r300] Fix reordering of fragment program instructions and register allocation
On 3/18/07, Nicolai Haehnle [EMAIL PROTECTED] wrote: I just realized I didn't send it to the list: There was yet another problem with reordering of instructions. The attached patch (which is against my earlier patch) should fix this. I can confirm this fixes my problems with the first patch. :) - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework
On 3/18/07, Brian Paul [EMAIL PROTECTED] wrote: All the Glean tests that check for specific rendering results already have an error margin. Can you be more specific about which tests are failing and how the error margin might need to be changed? -Brian I previously replied (but forgot to CC the list) about this; I think the precision error I saw in the examples on the piglet site wasn't really a precision error as one of the components was 1 instead of 0 and I didn't see this. I was probably half asleep and only looked at the first 3 components or something. Anyway, seems it's not a problem. :) - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework
I notice some failures with the example tests (R300) that seem to just be slight precision errors; I think you should add a margin for error because usually the hardware will implement things in a faster, perhaps less precise way. This lower precision is still good enough, though. On 3/17/07, Brian Paul [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: Hello, back when I was actively working on DRI drivers almost three years ago, I always felt uneasy about the fact that I didn't have an extensive array of tests that I could rely on to test for regressions. Now I've decided to do something about it. I've taken Glean and some code from Mesa and wrapped it with Python and cmake glue to - execute OpenGL tests without user interaction and - neatly format the results in HTML You can find the current version (and a sample HTML summary, to get an idea of what they look like at the moment) at http://homepages.upb.de/prefect/piglit/ The idea is to make testing dead simple for driver developers. I believe that Piglit already makes it quite simple, but I'm sure there's still room for improvement. My current plans are: - Hunt some bugs in R300, to get a better feeling for how the tool fares in practice - Integrate tests from Mesa; unfortunately, this needs manual work because those tests are mainly interactive, but it's definitely necessary to make this useful I'm also considering setting up a public repository somewhere, perhaps on Sourceforge. Please give it a try when you have a little time to spare and tell me if you find it useful (or more importantly, why you don't find it useful), and where it could be improved. I'll try to give it a try when I have some time. For now though I've added a link to Piglit from the Glean home page. -Brian - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [r300] Fix reordering of fragment program instructions and register allocation
This patch seems to break one of my longer fragment programs. I believe this is because it's running out of registers, but I haven't looked into it in detail yet. I think this patch should be committed, but directly followed by a patch to reduce the number of registers used. On 3/18/07, Nicolai Haehnle [EMAIL PROTECTED] wrote: There were a number of bugs related to the pairing of vector and scalar operations where swizzles ended up using the wrong source register, or an instruction was moved forward and ended up overwriting an aliased register. The new algorithm for register allocation is slightly conservative and may run out of registers before it's strictly necessary. On the plus side, it Just Works. Pairing of instructions is done whenever possible, and in more cases than before, so in practice this change should be a net win. The patch mostly fixes glean/texCombine. One remaining problem is that the code duplicates constants and parameters all over the place and therefore quickly runs out of resources and falls back to software. I'm going to look into that as well. Please test and commit this patch. If you notice any regressions, please tell me (but the tests are looking good). ~Nicolai - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [r300] Fix reordering of fragment program instructions and register allocation
Another thought; the same changed are probably needed for the vertprog code. I think there are also a lot of bugs there. On 3/18/07, Oliver McFadden [EMAIL PROTECTED] wrote: This patch seems to break one of my longer fragment programs. I believe this is because it's running out of registers, but I haven't looked into it in detail yet. I think this patch should be committed, but directly followed by a patch to reduce the number of registers used. On 3/18/07, Nicolai Haehnle [EMAIL PROTECTED] wrote: There were a number of bugs related to the pairing of vector and scalar operations where swizzles ended up using the wrong source register, or an instruction was moved forward and ended up overwriting an aliased register. The new algorithm for register allocation is slightly conservative and may run out of registers before it's strictly necessary. On the plus side, it Just Works. Pairing of instructions is done whenever possible, and in more cases than before, so in practice this change should be a net win. The patch mostly fixes glean/texCombine. One remaining problem is that the code duplicates constants and parameters all over the place and therefore quickly runs out of resources and falls back to software. I'm going to look into that as well. Please test and commit this patch. If you notice any regressions, please tell me (but the tests are looking good). ~Nicolai - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Announcing Piglit, an automated testing framework
This is very interesting and useful. Seems it's already showing some areas where improvement is required in the R300 driver. I'd suggest getting an account on freedesktop.org and a Git repository there. :) Sourceforge is... less than reliable. - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
