-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan Brandmeyer wrote:
> I am developing an OpenGL program targeted at GNU/Linux, and I'm trying
> to make sure that it works well on i830 and higher graphics chips. I've
> been going over the source code for the DRI driver trying to figure out
> exactly what the hardware is capable of. I'm confused on a few points,
> and I think that there may be an area here that I can help improve.
>
> First, exactly how many texture units are supported by hardware?
> glGetInteger( GL_MAX_TEXTURE_UNITS) returns 8, however
> i830_texblend.c:i830SetTexEnvCombine() only seems to allow GL_TEXTURE
> and GL_TEXTURE[0-3].
If that's on actual i830 or similar generation such as i845 or i865,
that's a bug. The hardware supports only 4 textures.
> i830_reg.h suggests that the hardware supports MAD instructions, and
> there is some mumbling about partially supporting
> GL_ATI_register_combine3 in i830_texblend.c. I'm interested in adding
> this support, but I need to know what the order of arguments is for all
> of the TEXBLENDOP_MODULATE_{2X_,4X_,}AND_ADD insns.
I don't think anyone knows for sure. It should be easy enough to write
a test program to figure it out experimentally.
The first step to doing this is to write a really basic optimizer that
can combine multiple stages into either MODULATE_AND_ADD or
BLEND_AND_ADD stages. This can free up some stages for expansion of,
for example, GL_MODULATE_SUBTRACT_ATI.
I make some mention of this on my todo list. See
http://dri.freedesktop.org/wiki/IanRomanickToDo
Some combinations of state will inevitably result in software fallbacks.
For example, the hardware can't do (tex0 * tex1 - diffuse) * specular *
tex2 dot tex3. Doing that would require 5 stages, and the hardware only
has 4.
> TEXBLENDARG_ACCUM. The i810 programmer's guide mentions support for an
> accumulator target as both a source and destination for the blend unit's
> insns, but I can't figure out the details. Is it just a temporary
> register, or does it automatically add anything stored into it? I've
> looked at the 855GM/GME GMCH datasheet, but it was way too high-level
> for me to gain any programming information from it.
There are 4 texture combine stages supported by the hardware. The
result of each combine stage can be stored in either the output or the
accumulator. The accumulator can then be used as a source for a later
combine stage.
This lets you express things like "(texture0 * texture1) + (texture2 dot
texture3)". The expression "texture0 * texture1" would be handled in
the first stage and stored in the accumulator. "texture2 dot texture3"
would be handled in the second stage and stored in the output. Stage 3
would calculate "output + accumulator" and store the result in output.
> Finally, if the hardware really supports up to 8 insns, swizzling, MAD,
> SUB, ADD, MUL, ADD_SIGNED, BLEND, DOT, and has two GP regs (CURRENT and
> ACCUM), would it be worth it to support GL_ARB_fragment_shader? Not
It would be impossible to support GL_ARB_fragment_shader. That
extension requires that values be stored as full-range floating point
values. It also requires that you be able to use calculated values as
texture coordinates.
> many programs could link and run, but it would be more convenient (for
> the programmer) than using ARB_register_combine + part of
> ATI_register_combine3. I'd be willing to help with this if someone can
> point me in the direction of Mesa/DRI's GLSL architecture docs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEyi+6X1gOwKyEAw8RAvG3AJ96vzIX5MpGUfSWpfDOQefz+uc4QQCgjnFn
4fMZiDGE9LZLMxbEnmkELuw=
=iC/1
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
