Intel i915 cannot swizzle TEX arguments

Please consider for update in hardy.

Justification:

Performing of such simple GL operations is a benefit for the LTS and does not then bar it from day to day users with Intel hardware who wish to run basic games and others applications.

For info. My test package is revisioned: 7.0.3~rc2-1ubuntu3.1~8.04

For the record, that's the upstream commit (for patch tag x-refs, etc.):

http://cgit.freedesktop.org/mesa/mesa/diff/?id=3369cd9a6f943365242d7832e69788d4aede9a8f

Fixed in intrepid.

X maintainers, do you think this is an appropriate SRU? Especially when looking at the ABI change of i915_emit_texld()? (or is that only internal?)

Philip, how can this be tested? I. e. what currently doesn't work under 8.04 which would work with this patch?

Without additional analysis into the ABI impact of the i915_emit_texld() change, I'm not comfortable with this patch as an SRU as currently written.

If the patch could be refactored to not change i915_emit_texld()'s parameters, that would alleviate the concerns.

Also, for those of us non-opengl guru's, mind explaining what 'swizzling' is? Wikipedia defined what it is, but not why it's important. Knowing this can help us determine the importance of the fix relative to its risk.

Martin,

Under Intel hardware Crystal Space shader apps cannot be run and I suspect (though have not tested) this may affect other game engines. This issue will also prevent the totally OSS game http://www.yofrankie.org/ from running on hardy with certain Intel hardware.

This can be tested by running the 'walktest' application within the OSS Crystal Space 3D SDK.

svn co https://crystal.svn.sourceforge.net/svnroot/crystal/CS/trunk CS_latest

To build CS at a basic level will require the following be installed:

build-essential
nvidia-cg-toolkit
bjam
zlib1g-dev
libpng12-dev
libjpeg62-dev
libasound2-dev
libx11-dev
libfreetype6-dev
libogg-dev
libvorbis-dev
libxxf86vm-dev

Build instructions can be found:

http://www.crystalspace3d.org/docs/online/manual/Unix.html#0

Before be able to run an application without installing on a system, you must:

export LD_LIBRARY_PATH=/home/me/path_to/CS_latest

Bryce,

Texture swizzling is the "art" of swapping the pixels around in a texture so that
when it is sent in 'X' format, it will be stored in exactly the same way it
would have been if it had been transferred using the original format. This
allows for greater transfer speeds, while the texture sizes don't change and
the geometry does not have to be modified in any way i.e. no overhead to
hardware.

I cannot see how the i915_emit_texld()'s can be skipped and investigation would
need to take place. I can discuss this with my fellow core Crystal Space developers.

There are other examples of swizzling of coords i.e. other vector operations, but I will keep it down so no bug bloating.

After a look with a fellow Crystal Space core dev, we find that i915_emit_texld() is local to the driver with the following amount of instances in the Mesa-7.0.3-rc2.orig i915 driver.

Mesa-7.0.3-rc2/src/mesa/drivers/dri/i915/i915_program.c:197
Mesa-7.0.3-rc2/src/mesa/drivers/dri/i915/i915_program.c:217
Mesa-7.0.3-rc2/src/mesa/drivers/dri/i915/i915_fragprog.c:214
Mesa-7.0.3-rc2/src/mesa/drivers/dri/i915/i915_fragprog.c:417
Mesa-7.0.3-rc2/src/mesa/drivers/dri/i915/i915_program.h:112
Mesa-7.0.3-rc2/src/mesa/drivers/dri/i915/i915_texprog.c:72

Being purely local it has no wider affect than the driver it is in and thus has no wide ABI implications.

The caveat here is that the i915tex driver also uses i915_emit_texld()'s locally and any issue or need for that to be looked at and maybe updated is a decision for the Ubuntu X team. Though... not being the default driver I would personally steer away from touching it until such a time it was necessary.

Thinking of as many ways as possible to justify inclusion... here goes another.

Ubuntu wanting to be at the forefront of the netbook arena would of want to offer as much functionality as possible on them. At present the vast majority of these devices are Intel GMA 950 graphics based and thus use i915. The inclusion of the patch submitted and the functionality it provides would only enhance Ubuntu 8.04 in this area running certain types of application.

Hey... the above is worth a go. :-D

Thanks for the update. SRU wise I'm ok with the patch if we get a test case description and proper testing on intel hardware for regressions.

For a simple applicable test case. See the test case on duplicate http://bugs.freedesktop.org/show_bug.cgi?id=10786 supplied by Nian Wu of Intel. This sample is a derivative of http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt - search 'Sample Usage'.

This should generate the error on an unpatched 8.04 and will process and output the correct data when the patch is applied.

Successful result:

White tex on screen.

I have now been running the patch since the 14th with no regression or other issues to date.

Just for the record:

  sudo apt-get install libglut3-dev
  gcc fptex_915.c -lglut

So if this lands in hardy-proposed, I'd like to keep it there for at least two weeks, otherwise I'm ok with it. It slightly bends the rules, but I see the benefit of enabling more software to run on 8.04 LTS on intel graphics.

For information I have this patch packaged up as '7.0.3~rc2-1ubuntu3.1~8.04'. For proposed and forward could this be copied or bumped to '7.0.3~rc2-1ubuntu3.2' so I can stay the same/upgrade to the official build. Many thanks.

I agree this should spend as long as needed in proposed until it is pushed out the door.

It seems that newly released Mesa 7.5 will solve the problem with i915 and many other chipsets.

More info:
http://www.phoronix.com/scan.php?page=news_item&px=NzE4OQ

http://sourceforge.net/mailarchive/forum.php?thread_name=49DBEC08.7070704%40vmware.com&forum_name=mesa3d-dev

VangelistX,

Any version >= 7.0.4 (mesa 7_0 tree) fixes this issue. All versions of Ubuntu after Hardy are not affected. Please refrain from adding incorrect static to bug reports when they are in a complete state and pending actioning i.e. Wishlist (though that means nothing will be done).

Regards

Phil

Phil,

thank you for more info. I didn't know that "Wishlist" in Launchpad means "to be in a complete state".

I think it's confusing. Maybe You should consider to change the status name to more intuitive ("CLOSED", "NO FEEDBACK NEEDED"?). or provide easy accessible descriptions of current status names?

VangelistX,

Yeah, the Wishlist bit could be confused, but this bug was reported, test cased, patch supplied, explained, confirmed as valid and fixed by the patch. It went Wishlist as being that it is for Hardy, it is a borderline case for inclusion being that it is not a security fix and dubious for a StableReleaseUpdate (SRU). So Wishlist it went to and that is where it has stayed for oh such a long time. :-)

Any changes to the status names etc. is going to be down to the LP devs. You may wish to raise it with them or on one of the lists.

Regards

Phil

Indeed this has sat orphaned for too long already. I close it as wontfix now, since it is really not worth (potentially) breaking existing installations to introduce new code.