On Llu, 2004-02-23 at 19:33, Dieter NÃtzel wrote:
> What about this (Not only for "AMD"):
>
> AMD recommends to perform memory copies with backward read operations
> instead of prefetch.
If you try that in the real world with cached data it gives really bad
results compared to prefetch - so its
>
> Yes, lefover is always 0 in this case so we could simplify that. Care
> to send a patch? Otherwise, I'll get to it later.
>
There is quite a few cases that could be more simplified, I just used the
bgr888->rgba conversion as an example. I can go through and work it out
for each conversion
Chris Ison wrote:
*helps if I send to the list*
Maybe I don't understand what you're saying.
ok atm, the code for texsubimage2d_bgr888_to_rgba looks partially like
this
#define DST_TEXELS_PER_DWORD 1
#define CONVERT_TEXEL( dst, src ) \
dst = PACK_COLOR__LE( src[0], src[1], src[2],
*helps if I send to the list*
> Maybe I don't understand what you're saying.
ok atm, the code for texsubimage2d_bgr888_to_rgba looks partially like
this
#define DST_TEXELS_PER_DWORD 1
#define CONVERT_TEXEL( dst, src ) \
dst = PACK_COLOR__LE( src[0], src[1], src[2], 0xff )
#define C
Chris Ison wrote:
I'm wondering though why the heck quakeworld actually uses so much
texsubimage2d calls. Typically, games specify textures at level load
time and leave them completely alone after that - at least those games I
profiled with oprofile never showed texsubimage2d calls. Is there
someth
Roland Scheidegger wrote:
I'm wondering though why the heck quakeworld actually uses so much
texsubimage2d calls. Typically, games specify textures at level load
time and leave them completely alone after that - at least those games I
profiled with oprofile never showed texsubimage2d calls. Is
> For texture RGB888 is that 24bit packed or with 8bits of empty ?
Looking at the texsubimage source for bgr888->rgba conversion, it
appears to be 24bits packed, but I could be wrong, all the macros make it a
little difficult to follow.
Am Montag, 23. Februar 2004 19:32 schrieb Alan Cox:
> On Llu, 2004-02-23 at 16:35, Ian Romanick wrote:
> > Alternately, this might be a case where writing a little assembly
> > conversion routine would help. If we assume at least a 486 instruction
> > set (eh-hem!), the core of the BGR to ARGB con
Alan Cox wrote:
On Llu, 2004-02-23 at 16:35, Ian Romanick wrote:
Alternately, this might be a case where writing a little assembly
conversion routine would help. If we assume at least a 486 instruction
set (eh-hem!), the core of the BGR to ARGB conversion should take about
6 or 7 instructions,
ADMIN: please ignore pending email
> I'm wondering though why the heck quakeworld actually uses so much
> texsubimage2d calls. Typically, games specify textures at level load
> time and leave them completely alone after that - at least those games I
> profiled with oprofile never showed texsubimag
On Llu, 2004-02-23 at 16:35, Ian Romanick wrote:
> Alternately, this might be a case where writing a little assembly
> conversion routine would help. If we assume at least a 486 instruction
> set (eh-hem!), the core of the BGR to ARGB conversion should take about
> 6 or 7 instructions, includin
Ian Romanick wrote:
Chris Ison wrote:
ok, looking of the oprofile output of libgl, r200_dri and
qw-client-glx, I decided to hunt for the function
texsubimage2d_bgr888_to_rgba which is at the top of the list at
22.6% of the time.
So, it looks like it's basically converting from one byte ord
Chris Ison wrote:
ok, looking of the oprofile output of libgl, r200_dri and qw-client-glx, I decided to
hunt for the function
texsubimage2d_bgr888_to_rgba which is at the top of the list at 22.6% of the time.
So, it looks like it's basically converting from one byte order to
another. There'
Chris Ison wrote:
Each time texutil_tmp.h is included by texutil.c, eight new functions
are generated, four for texsubimage2d and four for texsubimage3d.
Those functions are listed in the arrays seen at lines 488 and 500 of
texutil_tmp.h
um, apart from partial code duplications, is there any reas
On Sul, 2004-02-22 at 21:26, Chris Ison wrote:
> these functions out into all the different types so each conversion type is
> done as fast as possible. Looking at it atm, (using my unrelated exprience
> in audio sample format convertion) these could be dramatically spead up by
> doing doing up fun
> Each time texutil_tmp.h is included by texutil.c, eight new functions
> are generated, four for texsubimage2d and four for texsubimage3d.
> Those functions are listed in the arrays seen at lines 488 and 500 of
> texutil_tmp.h
um, apart from partial code duplications, is there any reason not to b
Chris Ison wrote:
ok, looking of the oprofile output of libgl, r200_dri and qw-client-glx,
I decided to hunt for the function
texsubimage2d_bgr888_to_rgba which is at the top of the list at
22.6% of the time.
I have tracked down the function to a define, but from there I don't
know wher
ok, looking of the oprofile output of libgl,
r200_dri and qw-client-glx, I decided to hunt for the function
texsubimage2d_bgr888_to_rgba which is at the top of the list at 22.6% of
the time.
I have tracked down the function to a define, but from there I don't know
where it comes from
fr
18 matches
Mail list logo
