Menu
▾
▴
mesa3d-dev
|
From: Brian P. <br...@va...> - 2001-03-27 19:54:23
|
Gareth Hughes wrote:
>
> CVSROOT: /cvsroot/mesa3d
> Module name: Mesa
> Repository: Mesa/src/
> Changes by: gareth@usw-pr-cvs1. 01/03/27 11:18:02
>
> Log message:
> Updates required for DRI drivers on mesa-3-5-branch.
>
> Modified files:
> Mesa/src/:
> imports.c mtypes.h texformat.c texstore.c texutil.c
>
> Revision Changes Path
> 1.9 +10 -8 Mesa/src/imports.c
> 1.33 +4 -1 Mesa/src/mtypes.h
> 1.4 +63 -36 Mesa/src/texformat.c
> 1.19 +13 -5 Mesa/src/texstore.c
> 1.19 +41 -1 Mesa/src/texutil.c
This code in texutil.c:
#define CONVERT_TEXEL_DWORD( src ) \
({ GLuint s = *(GLuint *)src; \
s = (((s & 0xfffefffe) >> 1) | \
((s & 0x00010001) << 15)); s; })
is not ANSI-legal.
I'll fix it up.
Gareth,
With these latest changes it appears to me that the Format and Type
fields in gl_texture_image are redundant with respect to the BaseFormat
and BaseType fields in the gl_texture_format struct. I'd like to
remove Format and Type from the former and use the later instead.
I'll work on that too.
-Brian
|
|
From: <s8...@ii...> - 2004-04-13 13:42:51
|
Ian Romanick <id...@us...> writes: > CVSROOT: /cvs/mesa > Module name: Mesa > Repository: Mesa/src/mesa/tnl/ > Changes by: idr@pdx. 04/04/12 15:40:55 > > Log message: > Conditionally compile code for x86 specific TNL codegen. This fixes problem > with x86-64 and PowerPC. > > Reported by: sublett on #dri-devel. > Here are the additional patches needed to get dri building on x86-64. The mesa linux-x86-64 config is still broken. Also there are some odd color bugs with r200, some objects turn dark or purple. I see this with simple programs like glxgears, but not in more complex things like UT2004. |
|
From: Brian P. <bri...@tu...> - 2004-04-13 14:18:34
|
Ronny V. Vindenes wrote: > Ian Romanick <id...@us...> writes: > > >>CVSROOT: /cvs/mesa >>Module name: Mesa >>Repository: Mesa/src/mesa/tnl/ >>Changes by: idr@pdx. 04/04/12 15:40:55 >> >>Log message: >> Conditionally compile code for x86 specific TNL codegen. This fixes problem >> with x86-64 and PowerPC. >> >> Reported by: sublett on #dri-devel. >> > > > Here are the additional patches needed to get dri building on > x86-64. The mesa linux-x86-64 config is still broken. Also there are > some odd color bugs with r200, some objects turn dark or purple. I see > this with simple programs like glxgears, but not in more complex > things like UT2004. Thanks. I've checked in the patches. -Brian |
|
From: Andreas S. <a.s...@gm...> - 2005-01-02 03:07:03
Attachments:
s3v_trident_build_fix.diff.txt
|
Am 24.12.2004 04:04:14 schrieb(en) Adam Jackson: > CVSROOT: /cvs/mesa > Module name: Mesa > Repository: Mesa/src/mesa/drivers/dri/trident/ > Changes by: ajax@gabe. 04/12/23 19:04:14 > > Log message: > Get trident building and -Werror clean. > unfortunately it doesnt build with make linux-dri-x86 have a look at attached patch. best regards, Andreas Stenglein |
|
From: Adam J. <aj...@nw...> - 2005-01-02 03:37:47
|
On Saturday 01 January 2005 22:12, Andreas Stenglein wrote: > Am 24.12.2004 04:04:14 schrieb(en) Adam Jackson: > > CVSROOT: /cvs/mesa > > Module name: Mesa > > Repository: Mesa/src/mesa/drivers/dri/trident/ > > Changes by: ajax@gabe. 04/12/23 19:04:14 > > > > Log message: > > Get trident building and -Werror clean. > > unfortunately it doesnt build with > make linux-dri-x86 > > have a look at attached patch. Applied, thanks. - ajax |
|
From: Keith W. <ke...@tu...> - 2005-05-31 06:46:03
|
Eric Anholt wrote: > CVSROOT: /cvs/mesa > Module name: Mesa > Repository: Mesa/src/mesa/drivers/dri/radeon/ > Changes by: anholt@gabe. 05/05/30 21:04:24 > > Log message: > Bugzilla #2195: Convert the radeon driver to the t_vertex interface. This cuts > about 200 lines from the code and 25k from the binary, while matching other > drivers more closely. In the worst case (tcl_mode=0) it appears to have > a performance cost of 4.4% +/- 0.3% on quake3 (800x600 demofours, 1ghz p3, > rv200). Tested on ut2004, ut, q3, projtex. Does this performance cost still apply since the recent change to runtime-generate x86 code for the t_vertex.c mechanism? Keith |
|
From: Eric A. <et...@lc...> - 2005-05-31 07:02:14
|
On Tue, 2005-05-31 at 07:45 +0100, Keith Whitwell wrote: > Eric Anholt wrote: > > CVSROOT: /cvs/mesa > > Module name: Mesa > > Repository: Mesa/src/mesa/drivers/dri/radeon/ > > Changes by: anholt@gabe. 05/05/30 21:04:24 > > > > Log message: > > Bugzilla #2195: Convert the radeon driver to the t_vertex interface. This cuts > > about 200 lines from the code and 25k from the binary, while matching other > > drivers more closely. In the worst case (tcl_mode=0) it appears to have > > a performance cost of 4.4% +/- 0.3% on quake3 (800x600 demofours, 1ghz p3, > > rv200). Tested on ut2004, ut, q3, projtex. > > Does this performance cost still apply since the recent change to > runtime-generate x86 code for the t_vertex.c mechanism? > > Keith Yes, this was tested after the runtime generation, and those new sse functions did show up in the oprofile. Would the loss of HAVE_ELTS matter? -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ an...@Fr... |
|
From: Keith W. <ke...@tu...> - 2005-05-31 07:08:48
|
Eric Anholt wrote: > On Tue, 2005-05-31 at 07:45 +0100, Keith Whitwell wrote: > >>Eric Anholt wrote: >> >>>CVSROOT: /cvs/mesa >>>Module name: Mesa >>>Repository: Mesa/src/mesa/drivers/dri/radeon/ >>>Changes by: anholt@gabe. 05/05/30 21:04:24 >>> >>>Log message: >>> Bugzilla #2195: Convert the radeon driver to the t_vertex interface. This cuts >>> about 200 lines from the code and 25k from the binary, while matching other >>> drivers more closely. In the worst case (tcl_mode=0) it appears to have >>> a performance cost of 4.4% +/- 0.3% on quake3 (800x600 demofours, 1ghz p3, >>> rv200). Tested on ut2004, ut, q3, projtex. >> >>Does this performance cost still apply since the recent change to >>runtime-generate x86 code for the t_vertex.c mechanism? >> >>Keith > > > Yes, this was tested after the runtime generation, and those new sse > functions did show up in the oprofile. > > Would the loss of HAVE_ELTS matter? > For q3, yes that would be an issue and would explain the above. I can't remember why you would lose HAVE_ELTS going to t_vertex.c though - I'll have a quick look and see if it can be restored. If the sse functions (like sse_movups etc) are showing up in the significant percentages, that's a little odd as they are the generators only and you'd expect q3 to only generate a few vertex functions... Keith |
|
From: Roland S. <rsc...@hi...> - 2005-05-31 10:55:30
|
Keith Whitwell wrote: > For q3, yes that would be an issue and would explain the above. I can't > remember why you would lose HAVE_ELTS going to t_vertex.c though - I'll > have a quick look and see if it can be restored. > > If the sse functions (like sse_movups etc) are showing up in the > significant percentages, that's a little odd as they are the generators > only and you'd expect q3 to only generate a few vertex functions... Indeed IMHO it is very odd anything vertex related makes a measurable difference in quake3, this 3-polys-per-object game is usually 100% fillrate bound, so a 4.5% difference is quite a lot. Last time I measured (some month ago), IIRC I didn't get that much difference with this patch. Roland |
|
From: Eric A. <et...@lc...> - 2005-05-31 22:24:31
|
On Tue, 2005-05-31 at 12:55 +0200, Roland Scheidegger wrote: > Keith Whitwell wrote: > > For q3, yes that would be an issue and would explain the above. I can't > > remember why you would lose HAVE_ELTS going to t_vertex.c though - I'll > > have a quick look and see if it can be restored. > > > > If the sse functions (like sse_movups etc) are showing up in the > > significant percentages, that's a little odd as they are the generators > > only and you'd expect q3 to only generate a few vertex functions... > Indeed IMHO it is very odd anything vertex related makes a measurable > difference in quake3, this 3-polys-per-object game is usually 100% > fillrate bound, so a 4.5% difference is quite a lot. Last time I > measured (some month ago), IIRC I didn't get that much difference with > this patch. Were you running at tcl_mode=0? I was running at a pretty low res on a card with decent fillrate, on a p4 at a low clockrate. I could see vertex code differences being more important than on most peoples' systems. -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ an...@Fr... |
|
From: Roland S. <rsc...@hi...> - 2005-06-01 00:14:11
|
Eric Anholt wrote: > Were you running at tcl_mode=0? > > I was running at a pretty low res on a card with decent fillrate, on a > p4 at a low clockrate. I could see vertex code differences being more > important than on most peoples' systems. On a radeon sdr 7200, 800x600 high quality, so you're right that should be more fillrate limited than your setup. I think I've tried with and without tcl and that didn't seem to make a difference in q3 neither. Roland |
|
From: Andreas S. <a.s...@gm...> - 2005-08-14 20:06:22
|
Am 11.08.2005 21:23:23 schrieb(en) Ian Romanick: > CVSROOT: /cvs/mesa > Module name: Mesa > Repository: Mesa/configs/ > Changes by: idr@gabe. 05/08/11 12:23:23 > > Log message: > Since Brian's recent commit, "-I/usr/X11R6/include/X11/extensions" is no > longer needed. but was it intended to delete the complete line X11_INCLUDES = -I/usr/X11R6/include from the linux-dri and the linux-indirect config? At least on my Suse 9.3 box this seems to be necessary, otherwise the build fails. greetings, Andreas > > Modified files: > Mesa/configs/: > freebsd-dri linux-dri linux-indirect > > Revision Changes Path > 1.10 +1 -1 Mesa/configs/freebsd-dri > http://cvs.freedesktop.org/mesa/Mesa/configs/freebsd-dri > 1.30 +0 -2 Mesa/configs/linux-dri > http://cvs.freedesktop.org/mesa/Mesa/configs/linux-dri > 1.2 +0 -2 Mesa/configs/linux-indirect > http://cvs.freedesktop.org/mesa/Mesa/configs/linux-indirect > |
|
From: Keith W. <ke...@tu...> - 2005-11-08 22:53:28
|
Ian Romanick wrote: > CVSROOT: /cvs/mesa > Module name: Mesa > Repository: Mesa/src/mesa/tnl/ > Changes by: idr@gabe. 05/11/08 14:40:26 > > Log message: > This patch adds the missing NV_vertex_program2 and NV_vertex_program3 > instructions to the various internal tables. It does not add support for > them to the parser nor does it add support for them to the program > interpreter. > > It also corrects some errors in the comments in program_instruction.h. > > This patch breaks the instruction union in t_vb_arbprogram.h. The opcode > field in that union was only 6 bits. When there were only 59+3 instructions > that worked fine. However, this patch increases the base instruction count > to 69. This requires 7 bits. The problem is that increasing the opcode > width to 7 bits increases the size of instruction::rsw to 33 bits. I've > increased the size of the union to 64-bit, but this is just a temporary hack > (and probably breaks the build on some systems). Probably better to drop the 'dword' member altogther and just clear the instructions with memset when required... Keith |
|
From: Gareth H. <ga...@va...> - 2001-03-27 20:10:48
|
Brian Paul wrote:
>
> This code in texutil.c:
>
> #define CONVERT_TEXEL_DWORD( src ) \
> ({ GLuint s = *(GLuint *)src; \
> s = (((s & 0xfffefffe) >> 1) | \
> ((s & 0x00010001) << 15)); s; })
>
> is not ANSI-legal.
>
> I'll fix it up.
If possible, can you do it without changing the template file? Thanks.
Inline functions should do the trick. And I just built standalone Mesa
and discovered this fact, not that I'm surprised or anything :-)
> With these latest changes it appears to me that the Format and Type
> fields in gl_texture_image are redundant with respect to the BaseFormat
> and BaseType fields in the gl_texture_format struct. I'd like to
> remove Format and Type from the former and use the later instead.
> I'll work on that too.
I'm still trying to work out the best way to handle format and type info
for the hardware-format images. So far, I've used types like
GL_UNSIGNED_SHORT_5_6_5 and so on, but kept the base format as one of
the original legal base format values (ie. I'm not using GL_BGRA
combined with the *_REV types). I'm ultra-busy with other stuff, so
feel free to do this.
I guess my biggest aim here is to remove all the massive case statements
that check the format and type info. It might be worth storing the
number of components in gl_texture_format as well, for instance.
-- Gareth
|
|
From: Gareth H. <ga...@va...> - 2001-03-27 21:58:00
|
Gareth Hughes wrote: > > > With these latest changes it appears to me that the Format and Type > > fields in gl_texture_image are redundant with respect to the BaseFormat > > and BaseType fields in the gl_texture_format struct. I'd like to > > remove Format and Type from the former and use the later instead. > > I'll work on that too. Don't do this -- it's broken. At the moment, when the hardware has to store GL_ALPHA textures in a GL_LUMINANCE_ALPHA format, for instance, texFormat->BaseFormat is incorrectly GL_LUMINANCE_ALPHA instead of GL_ALPHA. This is obviously broken (try running texenv on the 3.5 radeon driver). I'm going to undo and rethink this change. -- Gareth |
|
From: Brian P. <br...@va...> - 2001-03-27 22:40:16
|
Gareth Hughes wrote: > > Gareth Hughes wrote: > > > > > With these latest changes it appears to me that the Format and Type > > > fields in gl_texture_image are redundant with respect to the BaseFormat > > > and BaseType fields in the gl_texture_format struct. I'd like to > > > remove Format and Type from the former and use the later instead. > > > I'll work on that too. > > Don't do this -- it's broken. At the moment, when the hardware has to > store GL_ALPHA textures in a GL_LUMINANCE_ALPHA format, for instance, > texFormat->BaseFormat is incorrectly GL_LUMINANCE_ALPHA instead of > GL_ALPHA. This is obviously broken (try running texenv on the 3.5 > radeon driver). > > I'm going to undo and rethink this change. Yeah, I temporarily forgot about this problem too. There's a difference between the actual texture image storage 'format' and the 'format' used during the texture environment computations. -Brian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X