search for: texcoords

...t = *idx; >>> - if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) { >>> - for (result = 0; result < 8; result++) { >>> - if (fp->texcoord[result] == *idx) { >>> + if (sem == TGSI_SEMANTIC_GENERIC) { >>> + uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 : >>> 10; >>> + for (result = 0; result < num_texcoords; result++) { >>> + if (fp->texcoord[result] == *idx + 8) { >> >> maybe i'm too tired, but why exactly *idx + 8 ? > See nvfx...

...t = EMIT_OMIT; > uint result = *idx; > > - if (sem == TGSI_SEMANTIC_GENERIC && result >= 8) { > - for (result = 0; result < 8; result++) { > - if (fp->texcoord[result] == *idx) { > + if (sem == TGSI_SEMANTIC_GENERIC) { > + uint num_texcoords = (screen->eng3d->oclass < NV40_3D_CLASS) ? 8 : 10; > + for (result = 0; result < num_texcoords; result++) { > + if (fp->texcoord[result] == *idx + 8) { maybe i'm too tired, but why exactly *idx + 8 ? > + sem = TGSI_SEMANTIC_TEXCOORD; >...

A reworked version of 3 out of 4 patches mentioned earlier. [1/4]: Fixes nearly all piglit vertprog testcases, due to now being able to pass the results on to the fragment shader. V2: rename samplers to texcoords. [2/4]: Fixes shader compiler assertion errors, as some source registers do not exist for certain operations. Fixes several piglit tests when mesa is compiled with --enable-debug [3/4]: unchanged [4/4]: Dropped, requires a more substantial fix. As a quick-fix it's still useable though. Testers...

...9;t be packed, because that will break if the fragment shader doesn't use a vertex output. And there is no way to correct that when the fragment program comes up, other than recompiling the vertex shader, which would be very desirable to avoid having to do. Non-GLSL programs can only use the 8 texcoords, so there is no problem there since hardware supports 8 slots. Thus, I think my proposed solution is the simplest and most efficient approach. Any other solution would require much more, and slower, code in the Gallium drivers for nv30, nv40, and maybe Intel too.

On 11.01.2015 06:05, Ilia Mirkin wrote: > Can you elaborate a bit as to why that's the right thing to do? > > On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> If we capture transform feedback from n stream in (n-1) buffers we face a >> NULL buffer, use the buffer (n-1) to capture the output of stream n.

On 12.01.2015 01:57, Ilia Mirkin wrote: > On Sun, Jan 11, 2015 at 7:43 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 11.01.2015 06:05, Ilia Mirkin wrote: >>> Can you elaborate a bit as to why that's the right thing to do? >>> >>> On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann >>>

This makes the vertex buffer go to GART, not VRAM, and redoes the mapping to not use the UNSYNCHRONIZED access (which is meaningless on a VRAM buffer anyways). While we're at it, add some flushes for VBO data. Moving the vertex buffer from VRAM to GART makes glxgears work fully with NV30_SWTNL=1. The other changes just seem like a good idea. I'm not sure *why* moving the buffer from VRAM

On Sun, Jan 11, 2015 at 7:43 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 11.01.2015 06:05, Ilia Mirkin wrote: >> >> Can you elaborate a bit as to why that's the right thing to do? >> >> On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann >> <tobias.johannes.klausmann at mni.thm.de> wrote: >>>

If we capture transform feedback from n stream in (n-1) buffers we face a NULL buffer, use the buffer (n-1) to capture the output of stream n. This fixes one piglit test with nvc0: arb_gpu_shader5-xfb-streams-without-invocations Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/mesa/state_tracker/st_cb_xformfb.c | 5 +++++ 1 file changed, 5 insertions(+)

https://bugs.freedesktop.org/show_bug.cgi?id=70130 Priority: medium Bug ID: 70130 Assignee: nouveau at lists.freedesktop.org Summary: unable to compile fragment shader program Severity: normal Classification: Unclassified OS: Linux (All) Reporter: infyquest at gmail.com Hardware: x86 (IA32)

What is the simplest (namely: minimum number of libraries or conflicts) way to fill a polygon with a pattern? For example, suppose I have (in a graphic file, like a jpeg) the drawing of an "X". Then I fill a polygon (like a triangle) with this pattern, and get something like: X XXX XXXXX XXXXXXX (where the border "X"s could be truncated). I searched the rimage

For all these patches I'd say: testers are welcome. The first three patches seem good enough to push as we speak IMHO (so if you agree, go ahead!), whereas for the fourth I don't know if this is the desired way to fix. The result of these four patches is that NV34 gives a nearly-correct desktop experience, where only some fading animations appear broken. It's quite useable now! [1/4]:

The Wine development release 1.7.53 is now available. What's new in this release (see below for details): - Support for the various versions of XAudio. - More implementation of the Web Services DLL. - Improved OLE object embedding. - Various code cleanups in Direct3D. - New MAINTAINERS file and Signed-off-by requirement to improve the patch review process. - Various bug fixes.

nvfx_fragprog_assign_generic only allows for up to 10/8 texcoords for nv40/nv30. This fixes compilation of the varying-packing tests (although they still fail). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: 9.1 9.2 10.0 <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 +- 1 file changed, 1 inse...

...if(!nvfx->is_nv4x) goto nv3x_cflow; nv40_fp_brk(fpc); break; @@ -951,7 +951,7 @@ static boolean nvfx_fragprog_assign_generic(struct nv30_context *nvfx, struct nvfx_fpc *fpc, const struct tgsi_full_declaration *fdec) { - unsigned num_texcoords = nvfx->use_nv4x ? 10 : 8; + unsigned num_texcoords = nvfx->is_nv4x ? 10 : 8; unsigned idx = fdec->Range.First; unsigned hw; @@ -1002,7 +1002,7 @@ nvfx_fragprog_parse_decl_output(struct nv30_context* nvfx, struct nvfx_fpc *fpc, case 2: hw = 3; break; case 3: hw =...

https://bugs.freedesktop.org/show_bug.cgi?id=69376 Priority: medium Bug ID: 69376 Assignee: nouveau at lists.freedesktop.org Summary: F19 Gnome-3 does not display icons for All Applications QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All

The Wine development release 1.7.41 is now available. What's new in this release (see below for details): - More Known Folders supported in the shell. - Some more support for kernel job objects. - More MSI patches improvements. - Some theming fixes. - Various bug fixes. The source is available from the following locations:

The Wine development release 1.1.25 is now available. What's new in this release (see below for details): - A ton of translation updates. - Support for various Unicode file encodings in Notepad. - Improved memory management, especially for OpenGL. - Desktop menus now cleaned up automatically. - Beginnings of a windowscodecs DLL implementation. - Various bug fixes. The source is

The Wine development release 1.6-rc1 is now available. This is the first release candidate for the upcoming Wine 1.6. It marks the beginning of the code freeze period. Please give this release a good testing to help us make 1.6 as good as possible. What's new in this release (see below for details): - New implementation of the typelib creation support. - GLSL-based support for fixed

The Wine development release 2.7 is now available. What's new in this release (see below for details): - TCP and UDP connection support in WebServices. - Various shader improvements for Direct3D 11. - Improved support for high DPI settings. - Partial reimplementation of the GLU library. - Support for recent versions of OSMesa. - Window management improvements on macOS. - Various