Direct Rendering Infrastructure

bugzilla-daemon@... wrote:

> When indirect rendering is used, either because direct rendering is not
> available or 'LIBGL_ALWAYS_INDIRECT=y' is set, functions related to
> EXT_secondary_color, EXT_fog_coord, and EXT_blend_func_separate act as no-ops. 
> glxinfo reports that all of this functionality should be available.
> 
> The source of the problem is that the GLX protocol for the new functions does
> not exist on either the client-side or the server-side.       

I know this is a breach of protocol, but I'd like to discuss the patch 
that I have for this before attaching it to the bug report or committing it.

In both the client-side and the server-side g_render.c I have created 
some template macros for generating the GLX protocol stubs.  The 
client-side version was 3,600 lines of virtually identical code.  That 
bugs me.  If nothing else, it makes it difficult to determine which 
functions exist and which ones don't.  It also makes the process of 
adding new functions tedious and error prone.  I suspect that these 
files may have been automatically generated at one point, but the means 
for doing that are lost.  After committing this fix, I intend to convert 
almost all of the client-side g_render.c functions to use some form of 
template.

I would also like to eliminate indirect_wrap.h.  The only place that 
seems to be needed is in g_render.c and vertarr.c.  The templates will 
allow it to be eliminated from g_render.c, and it should be easy enough 
to modify vertarr.c.

My server-side goals are slightly more ambitious.  I intend to create a 
new header-file, dispatch_stubs.h or some such, that contains all of the 
templated functions.  Under normal circumstances, the templates will 
generate the __glxDisp_ and __glxDispSwap_ prototypes for the functions. 
  If the file is included and GLX_GENERATE_CODE is defined, the 
functions will be generated.  A new C file, dispatch_stubs.c, will be 
the only file to define GLX_GENERATE_CODE.  It will also contain the few 
functions that can't easilly be templatized.  g_render.c (server-side 
only), g_renderswap.c, g_disptab.h, and g_disptab_EXT.h will go away. 
The benefit is that new functions won't need to be added to a C file and 
a header file.

In the current code, a person must modify 5 source files 
(g_disptab_EXT.c, g_disptab_EXT.h, g_render.c, g_renderswap.c, and 
rensizetab.c) in order to add protocol for a new function.  My proposed 
changes will reduce that number to 3 (dispatch_stubs.h, g_disptab_EXT.c, 
and rensizetab.c).

There is some hand editing in the patch to trim out some other stuff.  A 
couple of the client-side library changes may no apply 100% cleanly.  If 
there's a problem, please let me know.

Ian Romanick wrote:
> I know this is a breach of protocol, but I'd like to discuss the patch 
> that I have for this before attaching it to the bug report or committing 
> it.
> 
> In both the client-side and the server-side g_render.c I have created 
> some template macros for generating the GLX protocol stubs.  The 
> client-side version was 3,600 lines of virtually identical code.  That 
> bugs me.  If nothing else, it makes it difficult to determine which 
> functions exist and which ones don't.  It also makes the process of 
> adding new functions tedious and error prone.  I suspect that these 
> files may have been automatically generated at one point, but the means 
> for doing that are lost.  After committing this fix, I intend to convert 
> almost all of the client-side g_render.c functions to use some form of 
> template.
> 
> I would also like to eliminate indirect_wrap.h.  The only place that 
> seems to be needed is in g_render.c and vertarr.c.  The templates will 
> allow it to be eliminated from g_render.c, and it should be easy enough 
> to modify vertarr.c.
> 
> My server-side goals are slightly more ambitious.  I intend to create a 
> new header-file, dispatch_stubs.h or some such, that contains all of the 
> templated functions.  Under normal circumstances, the templates will 
> generate the __glxDisp_ and __glxDispSwap_ prototypes for the functions. 
>  If the file is included and GLX_GENERATE_CODE is defined, the functions 
> will be generated.  A new C file, dispatch_stubs.c, will be the only 
> file to define GLX_GENERATE_CODE.  It will also contain the few 
> functions that can't easilly be templatized.  g_render.c (server-side 
> only), g_renderswap.c, g_disptab.h, and g_disptab_EXT.h will go away. 
> The benefit is that new functions won't need to be added to a C file and 
> a header file.
> 
> In the current code, a person must modify 5 source files 
> (g_disptab_EXT.c, g_disptab_EXT.h, g_render.c, g_renderswap.c, and 
> rensizetab.c) in order to add protocol for a new function.  My proposed 
> changes will reduce that number to 3 (dispatch_stubs.h, g_disptab_EXT.c, 
> and rensizetab.c).
> 
> There is some hand editing in the patch to trim out some other stuff.  A 
> couple of the client-side library changes may no apply 100% cleanly.  If 
> there's a problem, please let me know.

I usually don't comment on design decisions (because of too limited 
knowledge on the matter), but I think it's a great idea. As I've just 
figured out, it IS a pain to implement glx stuff currently, so I think 
it can only get better ;-). I don't quite understand yet all the 
template stuff, especially how to handle the cases when the size of the 
command depends on the parameter (I'm not a fluent speaker of cpp ;-)), 
but I'm sure it's a good idea nevertheless (even though in general I'm 
not a friend of macro overuse).

I think the patch is not complete though, I believe you'd need to add 
some missing values (like GL_FOG_COORDINATE_SOURCE, which can get used 
in glFog[if]v if you have the FogCoord Extension to singlesize.c and 
compsize.c), at least until before everything is converted to the new 
templates. I could be wrong though (well I've added them and it didn't 
hurt ;-)).

Roland

Roland Scheidegger wrote:

> Ian Romanick wrote:
> 
>> I know this is a breach of protocol, but I'd like to discuss the patch 
>> that I have for this before attaching it to the bug report or 
>> committing it.
>>
>> In both the client-side and the server-side g_render.c I have created 
>> some template macros for generating the GLX protocol stubs.  The 
>> client-side version was 3,600 lines of virtually identical code.  That 
>> bugs me.  If nothing else, it makes it difficult to determine which 
>> functions exist and which ones don't.  It also makes the process of 
>> adding new functions tedious and error prone.  I suspect that these 
>> files may have been automatically generated at one point, but the 
>> means for doing that are lost.  After committing this fix, I intend to 
>> convert almost all of the client-side g_render.c functions to use some 
>> form of template.
>>
>> I would also like to eliminate indirect_wrap.h.  The only place that 
>> seems to be needed is in g_render.c and vertarr.c.  The templates will 
>> allow it to be eliminated from g_render.c, and it should be easy 
>> enough to modify vertarr.c.
>>
>> My server-side goals are slightly more ambitious.  I intend to create 
>> a new header-file, dispatch_stubs.h or some such, that contains all of 
>> the templated functions.  Under normal circumstances, the templates 
>> will generate the __glxDisp_ and __glxDispSwap_ prototypes for the 
>> functions.  If the file is included and GLX_GENERATE_CODE is defined, 
>> the functions will be generated.  A new C file, dispatch_stubs.c, will 
>> be the only file to define GLX_GENERATE_CODE.  It will also contain 
>> the few functions that can't easilly be templatized.  g_render.c 
>> (server-side only), g_renderswap.c, g_disptab.h, and g_disptab_EXT.h 
>> will go away. The benefit is that new functions won't need to be added 
>> to a C file and a header file.
>>
>> In the current code, a person must modify 5 source files 
>> (g_disptab_EXT.c, g_disptab_EXT.h, g_render.c, g_renderswap.c, and 
>> rensizetab.c) in order to add protocol for a new function.  My 
>> proposed changes will reduce that number to 3 (dispatch_stubs.h, 
>> g_disptab_EXT.c, and rensizetab.c).
>>
>> There is some hand editing in the patch to trim out some other stuff.  
>> A couple of the client-side library changes may no apply 100% 
>> cleanly.  If there's a problem, please let me know.
> 
> 
> I usually don't comment on design decisions (because of too limited 
> knowledge on the matter), but I think it's a great idea. As I've just 
> figured out, it IS a pain to implement glx stuff currently, so I think 

Not only is it painful to do, it's painful to even figure out what to 
do.  I think that's the main reason we have so much rot in the GLX code.

> it can only get better ;-). I don't quite understand yet all the 
> template stuff, especially how to handle the cases when the size of the 
> command depends on the parameter (I'm not a fluent speaker of cpp ;-)), 
> but I'm sure it's a good idea nevertheless (even though in general I'm 
> not a friend of macro overuse).

Heh...that's the one good thing about the way the code is currently 
structured.  The functions in g_render.c that have variable size data 
(i.e., glFogfv) use a co-function, __glFogfv_size in this case, to 
determine the size.  The template that I have for those types of 
functions, which isn't in that patch, does something like:

	compsize = __ ## name ## _size(pname);

> I think the patch is not complete though, I believe you'd need to add 
> some missing values (like GL_FOG_COORDINATE_SOURCE, which can get used 
> in glFog[if]v if you have the FogCoord Extension to singlesize.c and 
> compsize.c), at least until before everything is converted to the new 
> templates. I could be wrong though (well I've added them and it didn't 
> hurt ;-)).

You need to do a 'cvs update'. :)  I added a *ton* of missing enums to 
singlesize.c and compsize.c yesterday.

Alex,

honestly I don't understand much of what you were writing about tiling
registers, PBDs, GBDs and so on. I don't have much experience with low
level aspects of graphics engines. The last one I programmed on the
register level was an original VGA under DOS many years ago. ;-) I'm a
bit confused that 2D and 3D engines can have different notions of tiling
of video memory without one of them showing corrupt output. They are
both rendering to the same frame buffer memory, aren't they? Could you
give me some basic explanation of how this works and maybe clear up some
fundamental misunderstandings (as far as my statements reveal them)?

More comments inline ...

On Wed, 14 Jan 2004 08:06:24 -0800 (PST)
Alex Deucher <agd5f@...> wrote:

> Felix,
>=20
>     Last night I did some thinging about the pitch and linear vs. tiled
> mode.  To be honest, I don't think it matters. 2D uses the GBD and can
> be tiled or linear.  3D uses the PBD and has to be tiled.  Since they
> are using different BDs, it shouldn't matter whether 2D is tiled or
> not.  for savagespan, we should use the tiled pitch whether or not 2D
> is tiled because they are writing to different BDs.  I think the reason
> linear provides a small speed boost is because in linear mode, 2D does
> not require the use of a tiling reg.  that frees tiling reg 0
> completely for use by the 3D engine whereas before it had to share it
> with the 2D side.   one thing I'm not clear on is the pitch in
> savagespan.  that's for sw fallbacks right?  are swfallbacks handled by
> the 2D driver?  should the destination for those be the GBD (2D) or the

They are handled by the 3D driver. That's when it needs the span
functions. I havn't looked into the details, but I think the 3D driver
needs to flush all drawing operations and wait for the 3D engine to go
idle. Then it can directly access the frame buffer through the span
functions.

> PBD (3D)? that would determine which pitch we need.  I presume the PBD
> since that is the destination for other 3D stuff (also in savage_dri.c
> the XAA fucntions in there write to the PBD rather than the GBD as the
> regular 2D accel functions do) and 2D accel can write to either BD you
> just have to set the destination right.
>=20
> The utah driver used Tim's 2D driver which used linear mode for 2D.  it
> just calcuated it's pitch based on the PBD in the 3D driver.  perhaps
> if we add a new item, psav->ul3DAperturePitch and calculate it the way
> ulAperturePitch is for tiled mode whether or not we are using tiled for
> 2D it should work and pitch shold be right whether or not 2D is tiled.

Hmm, I think psav->ulAperturePitch isn't used in the 2D driver. It's
only use is when it is passed to the 3D driver in SAVAGEDRIScreenInit.

>=20
> Does this make sense?

Probably, I just can't grasp all of it yet. ;-)

>=20
> Alex
>=20
[snip]

------------    __\|/__    ___     ___       -------------------------
 Felix       ___\_e -_/___/ __\___/ __\_____   You can do anything,
   K=FChling  (_____\=C4/____/ /_____/ /________)  just not everything
 fxkuehl@...       \___/   \___/   U        at the same time.

Hello.

drm loads cleanly, finds card, inits.

driver recognizes drm cleanly.  xvideo is broken, no 2d "acceleration" at all. 
Speed is equal to vesa driver.

glplanet exits with invalid texture size.
glxgears locks up X (sometime).

In any case there is nothing to see in 3d ;)

After trying 3d stuff and restarting X, X is unusable. Even after warm boot of 
the machine X is not usable. When starting the login manager it takes about 3 
minutes to get the picture completed. A shutdown/turnoff/restart "solves" the 
problem.

 regards marco

I fixed the pitch in savagespan today.  my assumption was right.  see
more below.

Alex

--- Felix Kühling <fxkuehl@...> wrote:
> Alex,
> 
> honestly I don't understand much of what you were writing about
> tiling
> registers, PBDs, GBDs and so on. I don't have much experience with
> low
> level aspects of graphics engines. The last one I programmed on the
> register level was an original VGA under DOS many years ago. ;-) I'm
> a
> bit confused that 2D and 3D engines can have different notions of
> tiling
> of video memory without one of them showing corrupt output. They are
> both rendering to the same frame buffer memory, aren't they? Could
> you
> give me some basic explanation of how this works and maybe clear up
> some
> fundamental misunderstandings (as far as my statements reveal them)?

I can't say I'm an expert either.  my understanding is that there is a
framebuffer (I think in linear format) and it is accessed by 3 bitmap
descriptors (global, primary, and secondary - 0x816c-0x817f). each
bitmap descriptor (BD) has 2 32 bit halfs: a low and a high part.  The
low part is the offset of the start of the framebuffer, the high part
defines the descriptor: bpp, stride, BCI enabled, size, linear/tile
format, etc. (incidently, the bitfields of the BDs and tiling regs seem
to have changed between families, hence my recent fixes). right now 2D
uses the global BD and 3D uses the primary BD.
All 2D and 3D drawing commands need to go through a BD to get to the
framebuffer.  they need to specify a BD as a destination. Stuff can get
to the framebuffer either linearly or tiled depending on the setup of
the BD.  The hardware must translate whatever format comes into the BDs
to the proper format in the framebuffer for display on your monitor.
Hence you can mix linear and tiled.  If you use a tiled format you also
need to set up a tiled surface register (0x48C40-0x48C50).  this may be
what does the translation from tiled to framebuffer happens since
linear just works, thus the final framebuffer is probably linear.
I'm not entirely sure as of yet how the tiled surface regs are
associated with a particular BD. Maybe it doesn't matter. I dunno.  For
tiled surface regs you need to specify the framebuffer offset, bpp,
tiled width, etc.  The tiled surface regs have to be set up to match
the tile format, etc. from the tiled BD that is using it.  I think
tiled surface regs are also used for textures, but I'm not sure how
that works yet. if you look in savage_dri.c tiled surface 0 is used for
front buffer, 1 for back, and 2 for depth:

OUTREG(0x48C40, value|(pSAVAGEDRI->frontOffset >> 5) );    /* front */ 
OUTREG(0x48C44, value|(pSAVAGEDRI->backOffset >> 5) );    /* back */
OUTREG(0x48C48, value|(pSAVAGEDRI->depthOffset >> 5) );    /* depth */


> 
> More comments inline ...
> 
> On Wed, 14 Jan 2004 08:06:24 -0800 (PST)
> Alex Deucher <agd5f@...> wrote:
> 
> > Felix,
> > 
> >     Last night I did some thinging about the pitch and linear vs.
> tiled
> > mode.  To be honest, I don't think it matters. 2D uses the GBD and
> can
> > be tiled or linear.  3D uses the PBD and has to be tiled.  Since
> they
> > are using different BDs, it shouldn't matter whether 2D is tiled or
> > not.  for savagespan, we should use the tiled pitch whether or not
> 2D
> > is tiled because they are writing to different BDs.  I think the
> reason
> > linear provides a small speed boost is because in linear mode, 2D
> does
> > not require the use of a tiling reg.  that frees tiling reg 0
> > completely for use by the 3D engine whereas before it had to share
> it
> > with the 2D side.   one thing I'm not clear on is the pitch in
> > savagespan.  that's for sw fallbacks right?  are swfallbacks
> handled by
> > the 2D driver?  should the destination for those be the GBD (2D) or
> the
> 
> They are handled by the 3D driver. That's when it needs the span
> functions. I havn't looked into the details, but I think the 3D
> driver
> needs to flush all drawing operations and wait for the 3D engine to
> go
> idle. Then it can directly access the frame buffer through the span
> functions.

in that case they would need to go through the PBD.

> 
> > PBD (3D)? that would determine which pitch we need.  I presume the
> PBD
> > since that is the destination for other 3D stuff (also in
> savage_dri.c
> > the XAA fucntions in there write to the PBD rather than the GBD as
> the
> > regular 2D accel functions do) and 2D accel can write to either BD
> you
> > just have to set the destination right.
> > 
> > The utah driver used Tim's 2D driver which used linear mode for 2D.
>  it
> > just calcuated it's pitch based on the PBD in the 3D driver. 
> perhaps
> > if we add a new item, psav->ul3DAperturePitch and calculate it the
> way
> > ulAperturePitch is for tiled mode whether or not we are using tiled
> for
> > 2D it should work and pitch shold be right whether or not 2D is
> tiled.
> 
> Hmm, I think psav->ulAperturePitch isn't used in the 2D driver. It's
> only use is when it is passed to the 3D driver in
> SAVAGEDRIScreenInit.
> 

It is used by the 2D driver if you are using tiling for 2D. 3D always
needs it.

> > 
> > Does this make sense?
> 
> Probably, I just can't grasp all of it yet. ;-)
> 
> > 
> > Alex
> > 
> [snip]
> 
> ------------    __\|/__    ___     ___      
> -------------------------
>  Felix       ___\_e -_/___/ __\___/ __\_____   You can do anything,
>    Kühling  (_____\Ä/____/ /_____/ /________)  just not everything
>  fxkuehl@...       \___/   \___/   U        at the same time.


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Michel D=C3=A4nzer wrote:
> On Tue, 2004-01-13 at 23:28, Roland Scheidegger wrote:
>=20
>> Michel D=C3=A4nzer wrote:
>>=20
>>> On Tue, 2004-01-13 at 21:12, Roland Scheidegger wrote:
>>>=20
>>>=20
>>>> Maybe not all necessary state is submitted?
>>>=20
>>> Maybe, but that doesn't really explain my observations, does it?
>>=20
>> Well for me there was no difference at all when running with=20
>> R200_DEBUG=3Dstate (except the huge speed difference of course),
>=20
>=20
> Did you redirect stderr to /dev/null or to a normal file?
Tried both, but even redirecting to /dev/null causes a large drop in
performance and otherwise there was no difference.

>> and since the alternating lighting doesn't appear to be random (as
>>  you've also observed) and I never get the correct colours I just=20
>> thought it's probably not timing related. But I'm certainly no
>> expert ;-)
>=20
>=20
> Neither am I... my guess has been that the lighting switch occurs on=20
> certain state transitions, but only under certain (timing or
> whatever) conditions.
>=20
>=20
>=20
>> Interesting you got multiple colour schemes, here it is strictly
>> limited to only 2.
>=20
>=20
> Maybe we're not using the same version? 4.14 here.
That's probably the reason, I'm using 4.05 (from suse 8.1). A quick
glance over the code shows the new version uses for instance more=20
complex lighting...

Roland

On Wed, 2004-01-14 at 11:33, Keith Whitwell wrote: 
> 
> What's going on here - is there something the hw can't handle?
> 
> +		  if ( fcmd[LIT_ATTEN_CONST] == 1.0 ) {
> +		     /* Can't do even constant attenuation, disable */
> +		     icmd[idx] &= ~( R200_LIGHT_0_ENABLE_RANGE_ATTEN << shift);

The refernce driver does this; excuse my ignorance, but maybe constant
attenuation of 1.0 is the same as no attenuation?

> Secondly - what's the ATTEN_XXX constant?  I realize that it's mine, but I 
> can't remember what it's all about...

I don't know what it's for, but again, the reference driver always sets
it to zero. :)


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Software libre enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Michel Dänzer wrote:
> On Wed, 2004-01-14 at 11:33, Keith Whitwell wrote: 
> 
>>What's going on here - is there something the hw can't handle?
>>
>>+		  if ( fcmd[LIT_ATTEN_CONST] == 1.0 ) {
>>+		     /* Can't do even constant attenuation, disable */
>>+		     icmd[idx] &= ~( R200_LIGHT_0_ENABLE_RANGE_ATTEN << shift);
> 
> 
> The refernce driver does this; excuse my ignorance, but maybe constant
> attenuation of 1.0 is the same as no attenuation?

Yes, that makes sense.  Reading the comment not the code.

The patch looks good - I'm happy to see it committed.

Keith

On Wed, 14 Jan 2004 03:12:37 +0100
Michel D=E4nzer <michel@...> wrote:

> On Wed, 2004-01-14 at 01:47, Felix K=FChling wrote:
> >=20
> > The funny thing is, that I'm seeing the same on Radeon (r100). It took
> > me a while to realize that this was the behaviour you were describing
> > ;-). I always thought the changing colors were intentional.=20
>=20
> So I used to think. :)
>=20
> > It makes sense since the color depends on whose move it is. But with=20
> > TCL disabled and with indirect rendering the colors don't change. I=20
> > also tried this on my ProSavage and it looks the same as with software=
=20
> > TCL and indirect rendering. Maybe taking a look at the endgame source c=
ode would shed
> > some light on this?
>=20
> I've been looking around it and even changing some things to see the
> effect, but no trace so far. I may well have missed something though,
> I'd appreciate if you took a look as well.

The version I tested was 4.05. I can't find the old sources so I'm
downloading the 4.14 sources now.

I just tested a 4.14 endgame binary. With TCL it looks like there is
only a little ambient light, diffuse (and specular?) lights aren't
working. The reflections of figures in every second square look like
they are lighted correctly, though. Colors don't change AFAICT.

Without TCL it looks correct.

Is this what you're seeing on r200 too?

Does someone have older xscreensaver sources?

>=20
>=20
> --=20
> Earthling Michel D=E4nzer      |     Debian (powerpc), X and DRI developer
> Software libre enthusiast    |   http://svcs.affero.net/rm.php?r=3Ddaenzer

Regards,
  Felix

------------    __\|/__    ___     ___       -------------------------
 Felix       ___\_e -_/___/ __\___/ __\_____   You can do anything,
   K=FChling  (_____\=C4/____/ /_____/ /________)  just not everything
 fxkuehl@...       \___/   \___/   U        at the same time.

On Wed, 2004-01-14 at 16:10, Brian Paul wrote: 
> Roland Scheidegger wrote:
> > 
> > I've just seen there are some fixes very recently in the drm module for
> > the cubic offsets which I've missed before (as I don't update the drm
> > module every time I'll compile the 3d driver).
> > Unfortunately, these fixes seem to effectively prevent ANY app which use
> > any texturing to work at all... (drmCommandWrite: -22).
> 
> Who checked in those changes?

I did, and they exposed a bug in the r200 3D driver (which didn't occur
with any textured apps in my testing though...), for which I then
checked in the fix posted by Andreas.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Software libre enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Roland Scheidegger wrote:

> pointblast:
> (both with hardware tcl and without) the points are almost
> invisible. IIRC this was already mentioned some time ago to be because
> all points are drawn with size 1 only.

Right.  Could you try it again with this patch.  You may need some 
changes to get it to apply.  If this works, can somebody commit it?

http://marc.theaimsgroup.com/?l=dri-devel&m=105862837814769&w=2

> occlude:
> GL_HP_occlusion_test is not supported in r200 driver, though I believe 
> the hardware should be able to support it (ATI supports this extension 
> in their driver).

I believe that requires some of the "advanced" Z-buffer functionality 
for which ATI has not released documentation.  I suspect it's related to 
their Hyper-Z stuff.

> fogcoord:
> doesn't work correctly with software mesa, all squares are white (test 
> says should be white -> gray -> black)
> GL_EXT_fog_coord is not implemented in r200 driver. Both the XiG and ATI 
> driver support this in their driver, so I guess the hardware should 
> support it too.

[snip]

> seccolor:
> works with hardware acceleration (with or without software tcl), but not 
> correctly with software mesa (all squares are red).

Both of these are due to missing (!) protocol support on both the client 
and the server.  I filed bug #1091 to XFree86 for this problem.

Ian Romanick wrote:
> Roland Scheidegger wrote:
> 
>> pointblast: (both with hardware tcl and without) the points are
>> almost invisible. IIRC this was already mentioned some time ago to
>> be because all points are drawn with size 1 only.
> 
> 
> Right.  Could you try it again with this patch.  You may need some 
> changes to get it to apply.  If this works, can somebody commit it?
> 
> http://marc.theaimsgroup.com/?l=dri-devel&m=105862837814769&w=2
This patch is only for radeon though. Will try to make it work with
r200, though if it's not similar I probably won't succeed...

>> occlude: GL_HP_occlusion_test is not supported in r200 driver,
>> though I believe the hardware should be able to support it (ATI
>> supports this extension in their driver).
> 
> 
> I believe that requires some of the "advanced" Z-buffer functionality
>  for which ATI has not released documentation.  I suspect it's
> related to their Hyper-Z stuff.
tough luck then...

>> fogcoord: doesn't work correctly with software mesa, all squares
>> are white (test says should be white -> gray -> black) 
>> GL_EXT_fog_coord is not implemented in r200 driver. Both the XiG
>> and ATI driver support this in their driver, so I guess the
>> hardware should support it too.
> 
> 
> [snip]
> 
>> seccolor: works with hardware acceleration (with or without
>> software tcl), but not correctly with software mesa (all squares
>> are red).
> 
> 
> Both of these are due to missing (!) protocol support on both the
> client and the server.  I filed bug #1091 to XFree86 for this
> problem.

Figured that out too. If I'd known you're going to fix it I wouldn't 
have tried to implement it. Thought it might be fun to implement some 
glx functionality, BIG BIG mistake!!! 2 dozen or so edited files later, 
fogcoord at least runs correctly, though I "skipped" some parts of the 
implementation (the pointer stuff, only floats, not doubles, likely 
numerous errors...) - didn't have time for secondary color ;-).

Roland

[replying to multiple people]

> They also enable the old, undocumented, dead and buried
> GL_S3_s3tc extension

http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt


> Note that the alpha decompression of DXT5 (in txformat_tmp.h) is 
> horribly broken - stupid bug, the version from the earlier patch is 
> actually correct (games likely never need this).

The sole reason of using DXT5 over DXT1, apart from working around below
mentioned HW "features" on GeForce 1-4 cards, is using the alpha channel and
we most certainly make a lot of use of the alpha channel of DXT3/5 textures
and I would expect other games do the same.


> further (you can get better than 16bit color accuracy by means of the 
> calculated colors, provided the GPU does the decoding in more 
> than 16bit).

To the best of my knowledge the only GPUs that don't do this are NVIDIA's
GeForce 1-4 cards with DXT1 (they use 32 bit precision for DXT3/5). You
definitely want to use 32 bit for doing the color1/color2 blending as the
artifacts are quite noticeable for e.g. lightmaps.


> dark gray, light gray or white... The improved encoder I have here 
> improves this a bit, but fundamentally it seems to be a hard 

Check out NVIDIA's encoder as a reference as it is the best out there.

http://developer.nvidia.com/object/nv_texture_tools.html


-- Daniel, Epic Games Inc.

Daniel Vogel wrote:
> [replying to multiple people]
> 
> 
>> They also enable the old, undocumented, dead and buried GL_S3_s3tc 
>> extension
> 
> 
> http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt
Yes, but everything there just says "unknown" - no compression format,
nothing interesting at all (except the format tokens), even how to
submit compressed textures is just a guess there! This is not what I'd
call documentation.

> 
>> Note that the alpha decompression of DXT5 (in txformat_tmp.h) is 
>> horribly broken - stupid bug, the version from the earlier patch is
>>  actually correct (games likely never need this).
> 
> 
> The sole reason of using DXT5 over DXT1, apart from working around 
> below mentioned HW "features" on GeForce 1-4 cards, is using the 
> alpha channel and we most certainly make a lot of use of the alpha 
> channel of DXT3/5 textures and I would expect other games do the 
> same.
Yes certainly. But software decompression of textures really should
never happen in games (performance of software rasterization really 
isn't good...), and I don't think current games have much use for 
reading back decompressed textures.

> 
>> further (you can get better than 16bit color accuracy by means of 
>> the calculated colors, provided the GPU does the decoding in more 
>> than 16bit).
> 
> 
> To the best of my knowledge the only GPUs that don't do this are 
> NVIDIA's GeForce 1-4 cards with DXT1 (they use 32 bit precision for 
> DXT3/5). You definitely want to use 32 bit for doing the 
> color1/color2 blending as the artifacts are quite noticeable for e.g.
>  lightmaps.
> 
> 
>> dark gray, light gray or white... The improved encoder I have here 
>> improves this a bit, but fundamentally it seems to be a hard
> 
> 
> Check out NVIDIA's encoder as a reference as it is the best out 
> there.
> 
> http://developer.nvidia.com/object/nv_texture_tools.html
I did take a look there earlier but
1) I couldn't figure out what the original license for the source code 
is (nvidia's license wouldn't permit the use of the source code for 
anything)
2) I have no idea if this is the same algorithm which is used in the 
DXT_TOOLS anyway
3) Being an offline solution it might not be suitable for online 
compression (might emphasize quality over performance too much)
4) at first look it seemed to miss the DXT5 encoder
5) It's way more fun to write an own implementation ;-)

Roland

> Yes certainly. But software decompression of textures really should
> never happen in games (performance of software rasterization really 

FWIW, that's how we handle support for cards that don't support texture
compression as we store our textures pre- compressed. I agree though that it
doesn't make sense to expose the extension if the hardware can't handle it.
The app is much better suited to work around the lack of texture compression
than DRI/Mesa.
 
BTW, Kyro I/II is an interesting example as they expose
GL_EXT_texture_compression_s3tc though only implement DXT1 in hardware.


> isn't good...), and I don't think current games have much use for 
> reading back decompressed textures.

Correct.


> I did take a look there earlier but

Sorry, I meant as a quality reference.


-- Daniel, Epic Games Inc.

Daniel Vogel wrote:

>>Yes certainly. But software decompression of textures really should
>>never happen in games (performance of software rasterization really 
> 
> FWIW, that's how we handle support for cards that don't support texture
> compression as we store our textures pre- compressed. I agree though that it
> doesn't make sense to expose the extension if the hardware can't handle it.
> The app is much better suited to work around the lack of texture compression
> than DRI/Mesa.

One case where having pure software decompression is interesting is 
indirect rendering.  I'd much rather send a compressed texture over 
ethernet than an uncompressed texture.  Of course, how interesting that 
actually is in practice seems to wax and wane as time goes by...

> BTW, Kyro I/II is an interesting example as they expose
> GL_EXT_texture_compression_s3tc though only implement DXT1 in hardware.

That is interesting.  I wonder if they still support the VQ from their 
older chips...