A new version (2.2.0006) of the nvidia Cg Toolkit was released in April 2009 with improvements and bug fixes. From the release notes (extract): * Now support pack_matrix() pragma to specify matrix layout order * Arrays of shaders can now be used in CgFX files * Added ability to query the supported profiles at runtime * Added API to programmatically control profiles returned as “latest” * Added API to discover the enumerants associated with a state * New program for dumping CgFX files (cgfxcat) * New program for dumping Cg’s version string (cginfo) * Assign GLSL texture resources as soon as a program is compiled rather than waiting until it gets loaded * Fixed the GL profiles to actually unbind programs in cgGLUnbindProgram(). * Fixed a problem with cgGLSetOptimalOptions() on non-NVIDIA GPUs. * Added an ATI_draw_buffers profile option for the GLSL profiles. * Generate tex2DGrad() functions for GLSL profile when using tex2D() function with derivatives. * Fixed the DCL statements for arrays in vs 2.0+ shaders (which were always incorrectly assumed to have a TEXCOORD semantic). * Fixed a bug in scanning files for #include statements when the last line of the file being included ended with an #endif and was missing an end-of-line character.
Created attachment 191827 [details, diff] patch against current ebuild for new ebuild What changed in the tarball: * Two new binaries: cginfo and cgfxcat.ebuild * Various new documentation, manpages and examples * License included in tarball (usr/local/Cg/docs/license.txt) differs from license in portage (/usr/portage/licenses/NVIDIA). Changes in the ebuild: * Since the package has since this release more than one binary, /opt/nvidia-cg-toolkit/bin is put into $PATH environment variable and the cgc binary isn't symlinked into /opt/bin! The rationale is, that I also could symlink the others binary but who know's how many binaries the package will have. So putting opt/nvidia-cg-toolkit/bin is put into $PATH seemed to me the better solutions on the long run. I added an einfo note about this change. * Since I haved to change the environment file again, I decided to generate it in the ebuild while installing. I think this solution is more flexible and we don't end with n different environment files in files folder. * Other than that, the download path had to be adjusted.
Created attachment 198500 [details, diff] patch against current ebuild for new ebuild Fixed dependencies for x86: cginfo needs libstdc++.so.5 on x86. Added a dependencies on virtual/libstdc++:3.3 for x86. I'm not sure, if I done it the right way, because devmanual seems not to like my approach (x86 use flag in deps). But on the other side, the dep is in this case mandatory as oposed to the example in devmanual. Also bumped EAPI=0 to EAPI=2. Would be nice, if someone checks, if I didn't miss something in the transition to EAPI2.
A newer version (2.2.0010) of the nvidia Cg Toolkit was released in October 2009 with improvements and bug fixes. From the release notes (extract): * Better performance when running on multicore CPUs * cgCombinePrograms now works with CG_OBJECT programs * Better memory behavior when a program is repeatedly recompiled * and others (see release notes)
Created attachment 206593 [details, diff] patch against current ebuild for new ebuild Patch is against latest version in portage tree (media-gfx/nvidia-cg-toolkit-2.1.0017) and the changes are identical to the former version (media-gfx/nvidia-cg-toolkit-2.2.0006, second patch) of this bug except the MY_DATE variable which is only needed to fetch the correct package. Note: License included in tarball (usr/local/Cg/docs/license.txt) still differs from license in portage (/usr/portage/licenses/NVIDIA).
A newer version (2.2.0017) of the nvidia Cg Toolkit was released in February 2010 with improvements and bug fixes. As a side note: If there is interest, I could proxy-maintain this package.
Created attachment 224585 [details, diff] patch against current ebuild for new ebuild Patch is against latest version in portage tree (media-gfx/nvidia-cg-toolkit-2.1.0017) and the changes are identical to the former versions (media-gfx/nvidia-cg-toolkit-2.2.0006, second patch and media-gfx/nvidia-cg-toolkit-2.2.0010) of this bug except the MY_DATE variable which is only needed to fetch the correct package. Note: License included in tarball (usr/local/Cg/docs/license.txt) still differs from license in portage (/usr/portage/licenses/NVIDIA).
Created attachment 253859 [details] Ebuild with applied patches This is the resulting ebuild with one change: virtual/glut is no longer present, so the ebuild depends on media-libs/freeglut directly. It compiles fine so far, but I haven't finished rebuilding ogre and crystalspace with it, yet.
Created attachment 253875 [details] Updated ebuild to not use /opt/ and symlinks This doesn't seem to be sufficient. CrystalSpace-1.4.0 can not find the modules: ========================================= crystalspace.plugin.load: Couldn't load plugin with class 'crystalspace.graphics3d.shader.combiner.glcg'! ========================================= With this ebuild crystalspace seems to work fine. Ogre is still to be tested.
Created attachment 253903 [details, diff] patch against current ebuild for new ebuild Here is the most recent NVIDIA Cg toolkit version. Most important change to previous releases is the Fermi support and support for tessellation programs. Sorry for posting it so late but I have no Internet connection at home for the last months :-( Again only the date string changed in the patch, so please also see the comments of my previous patches. About the installation location: As far as I know, the gentoo policy is to install all binary packages (e.g. packages only available from upstream as binary package) in /opt. So you might need to tweek build scripts to find NVIDIA Cg toolkit on gentoo. A good way is to look for the cgc executable and from that location look for the headers in ../include and libraries in ../lib.
Is there any progress on getting this into portage? Any overlay this ebuild is available from?
P.S: While you are at it, can you also incorporate the patches from pcsx2-overlay [1] ? (See bug #262477) [1] https://github.com/eatnumber1/pcsx2-overlay/tree/master/media-gfx/nvidia-cg-toolkit
*** Bug 339918 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > P.S: While you are at it, can you also incorporate the patches from > pcsx2-overlay [1] ? (See bug #262477) > > [1] > https://github.com/eatnumber1/pcsx2-overlay/tree/master/media-gfx/nvidia-cg-toolkit > I modified the pcsx2 ebuild to be updated to the current version so that it will install 3.0.0015 (which is the version number on the nVidia website; I don't know where this 3.0.0017 version number originated from). It supports multilib. I also added a "symlink_binaries" use flag which will automatically create symlinks for the libs, includes, and binaries to the default installation directories if the user chooses to make use of it. Perhaps having such a use flag can make everyone happy.
Created attachment 262883 [details] nVidia Cg toolkit ebuild supporting multilib for 64-bit, libstdc++ for 32-bit, and optional symlinks for binaries
Created attachment 262885 [details] nVidia Cg toolkit ebuild supporting multilib for 64-bit, libstdc++ for 32-bit, and optional symlinks for binaries (corrected typos)
Created attachment 267305 [details] Updated 3.0 ebuild Version and download location seem to have changed. Changed the ebuild to reflect this.
Created attachment 271811 [details] nvidia-cg-toolkit-3.0.0016.ebuild Added optional USE flags (doc examples) suggested by Zorzo Luca and applied on top of ebuild from portage by Beresk Leth in bug related to Braid ebuild (bug #349136). Also, removed the symlink magic and changed man installation from doins to doman - there's also an "issue" over there as there are manpages with .Cg and .CgFX extensions (portage won't install them with "is probably not a man page; skipping").
Created attachment 271931 [details, diff] patch against current ebuild for new ebuild Hi, Today I got a chance to look at the latest ebuild for version 3.0.0016 and found some issues with it: - By using the functions doman and dodoc the ebuild would "break" out of /opt/nvidia-cg-toolkit. - By using the environment file (80cgc-opt) from the files directory, LDPATH cannot be configured correctly. In attachment 191827 [details, diff] inspired from dev-util/nvidia-cuda-toolkit I started to generate the environment file which also can resolve this problem. - Instead of listing all single binaries, one could use globing (like in attachment 191827 [details, diff], when the new binaries were introduced). This is more future proof (e.g. if in a future version a binary is added, renamed or removed). I did a remix of my latest version (was for nvidia-cg-toolkit 3.0.0007) and the latest ebuild from this bug (nvidia-cg-toolkit 3.0.0016) and attached it to this bug. This new ebuild resolves all issues. ToDo: - Ebuild should be ported to EAPI 4. I took a quick look, seems that no change is needed but I'm not sure. I will look into the coming days into it. - I'm not really sure, but maybe unpacking could be simplified. Would be nice to get feedback from a gentoo developer to see what is missing so 3.0.x can finally enter the main tree.
(In reply to comment #18) > - By using the functions doman and dodoc the ebuild would "break" out of > /opt/nvidia-cg-toolkit. It would also work with FEATURES like no{doc,man} - at least I think they depend on do{doc,man} functions, correct me if i'm wrong. But, sincerely speaking, I have no idea if it is nice to „break out” from /opt with binary packages or not (would be good to know that for the future :).
One more thing - the Cg toolkit also has those strange manpages in directories like manCg and manCgFX - those should also be installed?
(In reply to comment #19) > (In reply to comment #18) > > - By using the functions doman and dodoc the ebuild would "break" out of > > /opt/nvidia-cg-toolkit. > > It would also work with FEATURES like no{doc,man} - at least I think they > depend on do{doc,man} functions, correct me if i'm wrong. But, sincerely > speaking, I have no idea if it is nice to „break out” from /opt with binary > packages or not (would be good to know that for the future :). Just for reference: In the past do{doc,html,man} were used. This changed with the bump to 2.1.0016 (04 Feb 2009) where everything did go to /opt as requested in bug #255867. Since that bump I kept it that way. I'm not aware that one could change the the path prefix for do{doc,html,man} which would at least for this ebuild the better solution. If not possible, it is maybe worth proposing a insinto like function for do{doc,man} for EAPI 5. (In reply to comment #20) > One more thing - the Cg toolkit also has those strange manpages in directories > like manCg and manCgFX - those should also be installed? Those are non-standard sections for man pages (see for example http://en.wikipedia.org/wiki/Man_page for common man page sections). I tried once to install them as manCg or redirect them to another section but couldn't get that to work nicely so ignored those man pages and just used the html pages if I needed a reference.
why is this not in the tree yet? we are 3 (!) years behind.
+*nvidia-cg-toolkit-3.1.0013 (15 Nov 2012) + + 15 Nov 2012; Justin Lecher <jlec@gentoo.org> files/80cgc-opt-2, + nvidia-cg-toolkit-2.1.0012.ebuild, -nvidia-cg-toolkit-2.1.0016.ebuild, + nvidia-cg-toolkit-2.1.0017.ebuild, nvidia-cg-toolkit-2.1.0017-r1.ebuild, + +nvidia-cg-toolkit-3.1.0013.ebuild: + Version BUmp, #270480, thanks Myckel Habets, Piotr Szymaniak and Jean-Marc + Hengen working on the ebuild; add multilib support, #262477, thanks Russell + Harmon and Dennis Schridde working on this; Add additional variables to + enviroment to find headers and libs, #344603 +
