Re: [Mesa-dev] [PATCH 1/2] Fix config check that claims to test if CXX supports -fvisibility=hidden option to actually test the C++ compiler.
On Tue, Apr 26, 2011 at 5:00 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Looking at this bit of autofoolery, I notice that at the moment it is just checking if CC supports -fvisibility=hidden twice Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- configure.ac | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 3b05ca3..37ea5e7 100644 --- a/configure.ac +++ b/configure.ac @@ -170,8 +170,10 @@ if test x$GXX = xyes; then AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden]) VISIBILITY_CXXFLAGS=-fvisibility=hidden CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS + AC_LANG_PUSH([C++]) AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]); + AC_LANG_POP([C++]) # Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed. CXXFLAGS=$save_CXXFLAGS I'm not super familiar with how AC_LANG_PROGRAM works, but this seems right as it should use whatever AC_LANG is. http://www.gnu.org/software/autoconf/manual/autoconf.html#Language-Choice http://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Test-Programs -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] Don't use -fvisibilty=hidden on cygwin
On Tue, Apr 26, 2011 at 5:00 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Using -fvisibility=hidden makes the current cygwin gcc emit a warning warning: visibility attribute not supported in this configuration; ignored for every single non-static symbol $ make clean make 21 | grep ignored | wc -l 6457 This is pretty annoying and makes it hard to spot other errors and warnings in the compiler output. It's not clear how to fix this. Possibly the correct solution is explicitly decorate all symbols with macros which annotate the expected visibility and evaluate to attribute(hidden/default) or dllexport depending on the target, as suggested at [1], but this would be a lot of work and misses the main advantage of -fvisibility=hidden (that you don't have to explicitly annotate everything :-)), so I guess we are supposed to know when -fvisibility isn't going to be useful and not use it. [1] http://gcc.gnu.org/wiki/Visibility Alternatively, the configuration check could be made more complex to avoid using this flag is the target isn't ELF or using the flag generates a warning You could add -Werror to the CFLAGS used for the visibility test since any host that's throwing warnings for something so simple probably has issues with visibility. Something like: diff --git a/configure.ac b/configure.ac index 8989c2b..ec662a3 100644 --- a/configure.ac +++ b/configure.ac @@ -152,7 +152,7 @@ if test x$GCC = xyes; then save_CFLAGS=$CFLAGS AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden]) VISIBILITY_CFLAGS=-fvisibility=hidden -CFLAGS=$CFLAGS $VISIBILITY_CFLAGS +CFLAGS=$CFLAGS $VISIBILITY_CFLAGS -Werror AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), [VISIBILITY_CFLAGS=; AC_MSG_RESULT([no])]); Does that do the right thing? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29460] GNU/Hurd support
https://bugs.freedesktop.org/show_bug.cgi?id=29460 --- Comment #9 from Jon TURNEY jon.tur...@dronecode.org.uk 2011-04-27 03:40:42 PDT --- (In reply to comment #8) simplify ifdef patch remains Commit simplify ifdef patch as 39cd791f3428ab48723fd4c73c4b1223e883ab2d so I can close this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] Don't use -fvisibilty=hidden on cygwin
On 27/04/2011 11:39, Dan Nicholson wrote: On Tue, Apr 26, 2011 at 5:00 AM, Jon TURNEY wrote: Alternatively, the configuration check could be made more complex to avoid using this flag is the target isn't ELF or using the flag generates a warning You could add -Werror to the CFLAGS used for the visibility test since any host that's throwing warnings for something so simple probably has issues with visibility. Something like: diff --git a/configure.ac b/configure.ac index 8989c2b..ec662a3 100644 --- a/configure.ac +++ b/configure.ac @@ -152,7 +152,7 @@ if test x$GCC = xyes; then save_CFLAGS=$CFLAGS AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden]) VISIBILITY_CFLAGS=-fvisibility=hidden -CFLAGS=$CFLAGS $VISIBILITY_CFLAGS +CFLAGS=$CFLAGS $VISIBILITY_CFLAGS -Werror AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), [VISIBILITY_CFLAGS=; AC_MSG_RESULT([no])]); Does that do the right thing? Yes, this works, and in fact this was the approach I initially tried, and seems more elegant. However, I was concerned about false negatives. As far as I can tell, nothing guarantees that the test program compiled by AC_LANG_PROGRAM() compiles without warnings, only without errors, so using -Werror might cause this test to fail for reasons unrelated to -fvisibility. Looking at this a bit more, though, a bit of googling seems to indicate we wouldn't be the first to use this construction, so perhaps it's ok :-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29460] GNU/Hurd support
https://bugs.freedesktop.org/show_bug.cgi?id=29460 Jon TURNEY jon.tur...@dronecode.org.uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27840] Enable mesa to be built for Cygwin -with-driver=dri
https://bugs.freedesktop.org/show_bug.cgi?id=27840 Bug 27840 depends on bug 29460, which changed state. Bug 29460 Summary: GNU/Hurd support https://bugs.freedesktop.org/show_bug.cgi?id=29460 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: choose 3-component float formats before 4-component formats
Reviewed-by: Marek Olšák mar...@gmail.com
On Wed, Apr 27, 2011 at 2:42 AM, bri...@vmware.com wrote:
From: Brian Paul bri...@vmware.com
If GL_RGB16F or GL_RGB32F is specified let's try the 3-component float
texture formats before trying the 4-component ones. Before this,
GL_RGB16/32F were treated the same as GL_RGBA16/32F.
---
src/mesa/state_tracker/st_format.c | 23 +--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 8e50dbd..4e7bef2 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -954,14 +954,24 @@ st_choose_format(struct pipe_screen *screen, GLenum
internalFormat,
/* prefer formats in order of data size, choosing 16-bit ones if equal
sized */
case GL_RGBA16F_ARB:
+ {
+ static const enum pipe_format formats[] = {
+ PIPE_FORMAT_R16G16B16A16_FLOAT,
+ PIPE_FORMAT_R32G32B32A32_FLOAT
+ };
+ return find_supported_format(screen, formats, Elements(formats),
+ target, sample_count, bindings);
+ }
case GL_RGB16F_ARB:
{
static const enum pipe_format formats[] = {
+ PIPE_FORMAT_R16G16B16_FLOAT,
PIPE_FORMAT_R16G16B16A16_FLOAT,
+ PIPE_FORMAT_R32G32B32_FLOAT,
PIPE_FORMAT_R32G32B32A32_FLOAT
};
return find_supported_format(screen, formats, Elements(formats),
- target, sample_count, bindings);
+ target, sample_count, bindings);
}
case GL_LUMINANCE_ALPHA16F_ARB:
{
@@ -1040,14 +1050,23 @@ st_choose_format(struct pipe_screen *screen, GLenum
internalFormat,
/* try a 32-bit format if available, otherwise fallback to a 16-bit one
*/
case GL_RGBA32F_ARB:
+ {
+ static const enum pipe_format formats[] = {
+ PIPE_FORMAT_R32G32B32A32_FLOAT,
+ PIPE_FORMAT_R16G16B16A16_FLOAT
+ };
+ return find_supported_format(screen, formats, Elements(formats),
+ target, sample_count, bindings);
+ }
case GL_RGB32F_ARB:
{
static const enum pipe_format formats[] = {
+ PIPE_FORMAT_R32G32B32_FLOAT,
PIPE_FORMAT_R32G32B32A32_FLOAT,
PIPE_FORMAT_R16G16B16A16_FLOAT
};
return find_supported_format(screen, formats, Elements(formats),
- target, sample_count, bindings);
+ target, sample_count, bindings);
}
case GL_LUMINANCE_ALPHA32F_ARB:
{
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g)
On Die, 2011-04-19 at 04:50 -0700, Jose Fonseca wrote: - Original Message - From: Michel Dänzer mic...@daenzer.net To: Cédric Cano cc...@interfaceconcept.com Cc: icthj tjour...@interfaceconcept.com, mesa-dev@lists.freedesktop.org Sent: Tuesday, April 19, 2011 10:39:41 AM Subject: Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g) [ Moving to the mesa-dev list ] On Fre, 2011-04-15 at 18:20 +0200, Cédric Cano wrote: Here you are a patch that adds big endian support for rv730 in r600 gallium driver. I used the mesa-demos to test the driver status on big endian platform. Except with demos using accumulation buffer, the rendering is the same as on Intel platform. Albeit there are still some artefacts with some demos. I manage to fix accumulation buffer demos but then, glReadPixels demos won't work. I still can figure out (like with r600c) what and when I must enable swap. It will depends on object's domains. That's what I tried to do in r600_cb and r600_create_sampler_view. That's probably because it hasn't been fully thought through yet how to deal with big endian CPUs vs. little endian GPUs in Gallium. When this was discussed previously, the basic rule decided was that all data passed across the Gallium driver interface was supposed to be little endian. That should probably be feasible in general for at least 'standard' pixel formats, but I'm afraid it doesn't really work for vertex data[0], which could be fed from the application (which will use CPU native byte order) to the GPU more or less directly. Maybe byte order should be handled explicitly by the Gallium format definitions, and then it would be up to the state tracker to use the appropriate byte order formats. José, have you had any further thoughts on this? I'm not sure either. The design principle we've used in the past for this in the past is to match what the hardware can and cannot do. It appears from Cédric's patch that r600 is able to toggle between bit/little ending values in vertices. Vertex/index buffers are indeed special because, unlike pixel data, the types can only be inferred at draw time, and not at data upload, so transcoding at BufferMap/BufferData is not really feasible. Does other hardware allow to toggle vertex data reads between little/big endian? If so then perhaps a per-vertex-element state bit indicating endianness might be sensible. Unfortunately, older Radeons can't do that TTBOMK. They only have a single vertex fetcher byte-swapping field, which applies to all vertex data (but only if it's fetched from outside of VRAM). Is there any scenario where vertex data wouldn't use the CPU's native byte order though? Anyway, it sounds like Cédric is still having issues with pixel data as well. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] GL_EXT_texture_shared_exponent
On Tue, Apr 26, 2011 at 4:57 PM, Brian Paul bri...@vmware.com wrote: On 04/26/2011 04:57 AM, Marek Olšák wrote: Hi, this series implements GL_EXT_texture_shared_exponent. The file rgb9e5.h has all its functions inline, because it's shared between classic and gallium. In that file, there are functions rgb9e5_to_float3 and float3_to_rgb9e5, which are used pretty much everywhere. I think I'd opt to put the code for this in gallium/util and include it in Mesa with a wrapper header. In the future I think we're more likely to use additional Gallium utility code in Mesa than vice versa. Here's a follow-up patch incorporating most of the suggestions: http://cgit.freedesktop.org/~mareko/mesa/commit/?id=1ac0d968df40dcb6911567bec1d8ec4ebcb6a2d2 Not sure how you would like the wrapper header to look like. FWIW I don't think it's terribly important though. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Organisation of the OpenCL state tracker
Hello, I'm very happy to have been accepted as a Google Summer of Code student ! Thanks to all who voted for my proposal, and thanks to Google. It's now the time to discuss the details of the implementation before beginning to code. I have already a fairly good idea of how I will implement things, but my question for today is Where do I place my code ?. Before I start explaining my question, I would say that I launched a Wordpress-based blog to share my progress and thoughts with everyone interested. It can be reached at http://steckdenis.wordpress.com. I'll try to keep it up to date with what I do. Its first post is about the object of this mail : do I work directly on Clover or do I copy it in the Mesa source tree, under src/gallium/state-trackers ? Currently, Clover already contains some code, but it’s mainly a build-system architecture and some files with function skeletons. The “useful” code seems to be less than 1000 lines long. If I work directly on Clover, I’ll make a library independant of Mesa for the software path, and relying on Gallium for the accelerated path. The problem is that I would have to reinvent the wheel at some places, for exemple where Gallium util functions exist. Another problem is that the Gallium3D interfaces are private, so it will be difficult to build Clover without the Mesa source code. If I create a state tracker in the gallium/ directory of Mesa, I will be able to use all the Gallium infrastructure and utils, and my work will be easily buildable by every person wanting to test it. This solution isn’t perfect though, as I will have to copy/paste and adapt the already-existing code of Clover in a new location, refactoring it from C++ to C. The blog post ends with a paragraph over the Gallium infrastructure used by the state trackers, that is to say the state tracker managers and the state trackers APIs (using Mapi). The problem is that OpenCL is only one API. The OpenCL context is created by OpenCL itself, not by EGL, WGL or GLX. So, do I have to break the Gallium3D model by not using the state trackers APIs, or do I have to create a state tracker API (that I will base on the OpenVG state tracker, very simple and that I understand very good) and a pass-through state tracker manager for OpenCL ? Finally, if I create a directory in the Mesa source tree, how do you want me to name it ? Clover, Coal (these two names appear in the current Clover code) or the already-suggested Chloride ? Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] prog_print: Add support for printing the TXD opcode.
On 04/26/2011 05:16 PM, Kenneth Graunke wrote:
---
src/mesa/program/prog_print.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
index 484596a..7c3b490 100644
--- a/src/mesa/program/prog_print.c
+++ b/src/mesa/program/prog_print.c
@@ -647,6 +647,7 @@ _mesa_fprint_instruction_opt(FILE *f,
case OPCODE_TXP:
case OPCODE_TXL:
case OPCODE_TXB:
+ case OPCODE_TXD:
fprintf(f, %s, _mesa_opcode_string(inst-Opcode));
if (inst-SaturateMode == SATURATE_ZERO_ONE)
fprintf(f, _SAT);
@@ -654,6 +655,12 @@ _mesa_fprint_instruction_opt(FILE *f,
fprint_dst_reg(f,inst-DstReg, mode, prog);
fprintf(f, , );
fprint_src_reg(f,inst-SrcReg[0], mode, prog);
+ if (inst-Opcode == OPCODE_TXD) {
+ fprintf(f, , );
+ fprint_src_reg(f,inst-SrcReg[1], mode, prog);
+ fprintf(f, , );
+ fprint_src_reg(f,inst-SrcReg[2], mode, prog);
+ }
fprintf(f, , texture[%d], , inst-TexSrcUnit);
switch (inst-TexSrcTarget) {
case TEXTURE_1D_INDEX: fprintf(f, 1D);break;
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g)
- Original Message - On Die, 2011-04-19 at 04:50 -0700, Jose Fonseca wrote: - Original Message - From: Michel Dänzer mic...@daenzer.net To: Cédric Cano cc...@interfaceconcept.com Cc: icthj tjour...@interfaceconcept.com, mesa-dev@lists.freedesktop.org Sent: Tuesday, April 19, 2011 10:39:41 AM Subject: Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g) [ Moving to the mesa-dev list ] On Fre, 2011-04-15 at 18:20 +0200, Cédric Cano wrote: Here you are a patch that adds big endian support for rv730 in r600 gallium driver. I used the mesa-demos to test the driver status on big endian platform. Except with demos using accumulation buffer, the rendering is the same as on Intel platform. Albeit there are still some artefacts with some demos. I manage to fix accumulation buffer demos but then, glReadPixels demos won't work. I still can figure out (like with r600c) what and when I must enable swap. It will depends on object's domains. That's what I tried to do in r600_cb and r600_create_sampler_view. That's probably because it hasn't been fully thought through yet how to deal with big endian CPUs vs. little endian GPUs in Gallium. When this was discussed previously, the basic rule decided was that all data passed across the Gallium driver interface was supposed to be little endian. That should probably be feasible in general for at least 'standard' pixel formats, but I'm afraid it doesn't really work for vertex data[0], which could be fed from the application (which will use CPU native byte order) to the GPU more or less directly. Maybe byte order should be handled explicitly by the Gallium format definitions, and then it would be up to the state tracker to use the appropriate byte order formats. José, have you had any further thoughts on this? I'm not sure either. The design principle we've used in the past for this in the past is to match what the hardware can and cannot do. It appears from Cédric's patch that r600 is able to toggle between bit/little ending values in vertices. Vertex/index buffers are indeed special because, unlike pixel data, the types can only be inferred at draw time, and not at data upload, so transcoding at BufferMap/BufferData is not really feasible. Does other hardware allow to toggle vertex data reads between little/big endian? If so then perhaps a per-vertex-element state bit indicating endianness might be sensible. Unfortunately, older Radeons can't do that TTBOMK. They only have a single vertex fetcher byte-swapping field, which applies to all vertex data (but only if it's fetched from outside of VRAM). Is there any scenario where vertex data wouldn't use the CPU's native byte order though? Not really. I suppose that making it explicit that vertex data is always assumed to be in the native byte order would make both driver implementation easy, and draw module implementation too. Anyway, it sounds like Cédric is still having issues with pixel data as well. I don't know what the problem may be. The semantics of some pixel formats are a bit tricky: e.g., while R8G8B8A8 has a reverse byte order equivalent (A8B8G8R8), other formats e.g., R5G6B5, do not. I also don't know how much of this problem comes from the GL API, or is self inflicted by the Mesa state tracker or Gallium abstraction. Can hardware easily toggle the byte order of pixel data as well? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA - GL_RGB
Am 26.04.2011 19:35, schrieb Tristan Schmelcher: On 26 April 2011 08:20, Roland Scheidegger srol...@vmware.com wrote: Am 26.04.2011 01:15, schrieb Tristan Schmelcher: Hello, I have an OpenGL app where I'm writing video frames to textures. The video frames are semantically opaque but the alpha in the source pixels is set to 0xff, so I have been using glTexImage2D with format=GL_RGBA and internalFormat=GL_RGB to indicate that the input has a valid alpha channel but that the OpenGL implementation could discard it if it wanted to (e.g., if the hardware had native support for GL_RGB which was faster than its GL_RGBA support, or something). This has worked well for me on most systems, but today I found that it results in poor glTexSubImage2D() performance on an Intel IGDNG_M GPU (i965-based) with MESA 7.7.1 (using Ubuntu Lucid). Because internalFormat is GL_RGB instead of GL_RGBA, _mesa_texstore_argb takes a slow path by using _mesa_swizzle_ubyte_image instead of memcpy_texture. Wouldn't it make sense for _mesa_texstore_argb to use memcpy_texture in this case? Or maybe it is right to not do that since there is no way for it to know that the alpha component in the input is already set to 0xff ... but in that case shouldn't it at least take the third path--the one that uses PACK_COLOR_(0xff, ...) ? memcpy is pretty much out of the question - it is quite possible other implementations would do this, but it's tricky. Most hw probably has some bit which it can set so sampling from such a texture would always return 1.0 for alpha regardless the actual values, but this is a generic function shared by all drivers hence it can't assume that. And even if it could, this can well break something else if you use the texture for something not directly related to sampling. Some PACK_COLOR_ path should work, it's probably not taken because there are about 3 million different cases (based on src/dst/internal format etc.) which you could code separately and this one just isn't one of it for which this is done. Besides, I'm not sure how much faster this is compared to _mesa_swizzle_ubyte_image (the big perf hit you take is usually with the fully general path with the temp image). In any case it would still be slower than memcpy. I guess that's sort of what I expected. I'll just have to use GL_RGBA after all then. :/ Separately, if I coded and perf-tested a PACK_COLOR_ path for this, is that something that people would be interested in taking into MESA? I think it would be ok though I can't speak for others. As long as the code is simple enough. I believe the idea was to only special-case the most common cases to keep the code sane, but supplying RGB data in RGBA form seems like a valid case to me. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
Hi Bryan, Am Mittwoch, den 27.04.2011, 09:31 -0500 schrieb Bryan Cain: Yes, I got MC working on nv50 but couldn't get the iDCT to work properly. I still need to send in the patches for what I did accomplish. Should I send them to the mesa-dev mailing list and just label them as being for the pipe-video branch? Looks like I missed your last mail, mhm I would guess that depends on the patches you made. Did you change the driver, state tracker or auxiliary stuff? Just rebase them to the current branch and then send them to me and cc the list so if there are changes to the driver the other nvidia developer can also get a look on them. Regarding the not working idct on nvidia hardware I would guess that we use something that the driver currently doesn't supports, like multiple render targets, disabled opengl rasterisation rules, unsupported intermediate buffer format or something else. Try again with the latest branch, since I have added some checks for unsupported stuff that will now report an error, which was silently failing before. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment, with more comments
Again, with a more detailed explanation added as comments.
On 20.04.2011 17:33, Christoph Bumiller wrote:
On 04/19/2011 04:00 AM, Christoph Bumiller wrote:
On 16.04.2011 18:50, Christoph Bumiller wrote:
I hope the new version is correct, the commit message describes why I
did the first change, and the second change is described in a comment.
Note that the MAD for inversion uses Height - 1 instead of Height.
With this, piglit glsl-arb-fragment-coord-conventions and
fbo-depth-sample-compare pass on nvc0.
I was assuming that integer pixel centers for size 100 range from 0 to
99 and half-integer pixel centers from 0.5 to 99.5.
Attached a better version of the patch, potentially saving an
instruction and avoiding precision issues with NEAREST filtering that
made piglit's blending-in-shader fail.
The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was
r600 classic, which should also work more correctly now since (at
least according to gallium caps) it uses half-integer pixel center,
and for H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5.
Please review.
Unfortunately I found another small error making a more precise piglit
test that draws to a float buffer instead of mangling the coordinate
like the original test does, which conceals errors.
Now there's a dependency again on whether inversion is actually done or
not, so I added a check on the inversion constant in the shader, but
maybe adding additional uniforms or even adjusting
STATE_FB_WPOS_Y_TRANSFORM dependent on the coordinat convention might be
nicer ?
Sorry for not noticing right away,
Christoph
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From 1353940f25d8566554621e907938da1e294d9a77 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Wed, 27 Apr 2011 20:51:50 +0200
Subject: [PATCH 1/2] mesa,st/mesa: fix WPOS adjustment
---
src/mesa/program/prog_statevars.c|4 +-
src/mesa/program/prog_statevars.h|2 +-
src/mesa/state_tracker/st_mesa_to_tgsi.c | 110 +++---
3 files changed, 74 insertions(+), 42 deletions(-)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index 1fd26f4..d94d7fe 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -602,11 +602,11 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index state[],
value[0] = 1.0F;
value[1] = 0.0F;
value[2] = -1.0F;
-value[3] = (GLfloat) (ctx-DrawBuffer-Height - 1);
+value[3] = (GLfloat) ctx-DrawBuffer-Height;
} else {
/* Flipping Y upside down (XY) followed by identity (ZW). */
value[0] = -1.0F;
-value[1] = (GLfloat) (ctx-DrawBuffer-Height - 1);
+value[1] = (GLfloat) ctx-DrawBuffer-Height;
value[2] = 1.0F;
value[3] = 0.0F;
}
diff --git a/src/mesa/program/prog_statevars.h
b/src/mesa/program/prog_statevars.h
index 9fe8d81..04af3f4 100644
--- a/src/mesa/program/prog_statevars.h
+++ b/src/mesa/program/prog_statevars.h
@@ -120,7 +120,7 @@ typedef enum gl_state_index_ {
STATE_PT_BIAS, /** Pixel transfer RGBA bias */
STATE_SHADOW_AMBIENT,/** ARB_shadow_ambient fail value; token[2]
is texture unit index */
STATE_FB_SIZE, /** (width-1, height-1, 0, 0) */
- STATE_FB_WPOS_Y_TRANSFORM, /** (1, 0, -1, height-1) if a FBO is bound,
(-1, height-1, 1, 0) otherwise */
+ STATE_FB_WPOS_Y_TRANSFORM, /** (1, 0, -1, height) if a FBO is bound,
(-1, height, 1, 0) otherwise */
STATE_ROT_MATRIX_0, /** ATI_envmap_bumpmap, rot matrix row 0 */
STATE_ROT_MATRIX_1, /** ATI_envmap_bumpmap, rot matrix row 1 */
STATE_INTERNAL_DRIVER /* first available state index for drivers
(must be last) */
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index c07739f..a41e5b1 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -752,37 +752,15 @@ compile_instruction(
/**
- * Emit the TGSI instructions to adjust the WPOS pixel center convention
- * Basically, add (adjX, adjY) to the fragment position.
- */
-static void
-emit_adjusted_wpos( struct st_translate *t,
-const struct gl_program *program,
-GLfloat adjX, GLfloat adjY)
-{
- struct ureg_program *ureg = t-ureg;
- struct ureg_dst wpos_temp = ureg_DECL_temporary(ureg);
- struct ureg_src wpos_input = t-inputs[t-inputMapping[FRAG_ATTRIB_WPOS]];
-
- /* Note that we bias X and Y and pass Z and W through unchanged.
-* The shader might also use gl_FragCoord.w and .z.
-*/
- ureg_ADD(ureg, wpos_temp, wpos_input,
-ureg_imm4f(ureg, adjX, adjY, 0.0f,
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
[Sending this message to the list since I accidentally sent it to the list earlier from a non-subscribed address.] 2011/4/26 Christian König deathsim...@vodafone.de Am Dienstag, den 26.04.2011, 17:53 + schrieb youne...@gmail.com: Hi Christian, Thanks for spending so much time on continuing this. I haven't really touched it since you started, but someone else had some patches for basic NV50 support. I don't recall who but I hope they can comment and are interested in getting their changes merged. Also, your implementation of interlaced MC breaks older chips that lack shader control flow if I'm not mistaken, but that can probably be fixed without much trouble.. Finally, someone else (Jimmy Rentz) had some patches that implemented hardware decoding on NV40 chips, but they were never merged into nouveau DRM and the pipe-video patches won't apply anymore anyhow. Those changes required a bit of work in pipe-video to support planar surfaces, but it worked quite well with the old vl_compositor. Recently Ben Skeggs added HW decoder bits to nouveau's DRM so if anyone is motivated enough to rework the userspace side it will require proper planar surface support in pipe-video. (This is just an FYI for anyone who is paying attention to pipe-video.) Cheers. If I remember correctly Bryan Cain was working on getting this to work again on NV50, he had MC working, but was struggling with the iDCT code. I also stumbled over the issue of planar texture resources, and solved it by implementing an abstraction class that uses up to three separate textures to emulate the behaviour of an YV12 or NV12 texture. If a hardware driver has native support for planar buffers it should be easy to override the creation function and use a native buffer instead. So things like: native idct - shader base mc or shader based idct - native mc should now be easily possible. But there is still allot of work todo. Regards, Christian. Yes, I got MC working on nv50 but couldn't get the iDCT to work properly. I still need to send in the patches for what I did accomplish. Should I send them to the mesa-dev mailing list and just label them as being for the pipe-video branch? Regards, Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR to TGSI translator
On Tue, Apr 26, 2011 at 12:26 AM, Bryan Cain bryanca...@gmail.com wrote:
Hi,
In the last week or so, I've been working on a direct translator from
GLSL IR to TGSI that does not go through Mesa IR. Although it is still
a work in progress, it is now working and very usable. So before I go
on, here is a link to the branch I've pushed to GitHub:
https://github.com/Plombo/mesa/tree/glsl-130
My main objective with this work is to make GLSL 1.30 support feasible
on Gallium drivers. From what I understand, it would be difficult or
impossible to implement integer-specific opcodes such as shifting and
bit masking in Mesa IR, since it only supports floats. TGSI, on the
other hand, doesn't have this problem, and already supports most or all
of the functionality required by GLSL 1.30.
Unfortunately, TGSI doesn't have everything we need yet. There's
opcodes for binary AND, OR, XOR, etc. and a few integer operations,
but it's incomplete. It shouldn't be a big deal to add what's missing
but it'll take a little time.
I think everyone agrees that we want to eventually ditch Mesa's IR. I
_think_ that the only classic Mesa driver that uses Mesa IR and hasn't
been deprecated by a Gallium driver, or already weaned from Mesa IR is
swrast. How much does the i965 driver still rely on swrast for
fallbacks? Do the Intel people see need for a GLSL IR executor for
swrast?
The translator started as a modified version of ir_to_mesa, and that
origin is still obvious from reading the code. Many parts of ir_to_mesa
are still untouched - glsl_to_tgsi is still a long way away from
eliminating all traces of Mesa IR. It also contains a significant
amount of code adapted from st_mesa_to_tgsi, but modified to generate
TGSI code from the glsl_to_tgsi_instruction class instead of using Mesa
IR. (It actually still generates Mesa IR instructions, but that could
be safely removed at some point since the generated Mesa IR instructions
are not actually used for anything.) I'm planning to push more of the
conversion to TGSI higher up in the stack in the future, although the
remaining remnants of Mesa IR (such as the Mesa IR opcodes used by most
of glsl_to_tgsi) aren't doing any harm.
I finally found a little time to look over your code. As you said,
it's basically a copy paste of the ir_to_mesa.cpp and
st_mesa_to_tgsi.c code at this time. Do you plan to eliminate all
remnants of Mesa IR there before adding support for GLSL 1.30? One
easy step would be to replace use of Mesa IR opcodes with TGSI opcodes
and add new TGSI opcodes for integer ops.
Since the _mesa_optimize_program function is vital to generating
optimized code with ir_to_mesa, and it is not available when not using
Mesa IR, I've written some new optimization passes for
glsl_to_tgsi_visitor that perform dead code elimination and
consolidation of the temporary register space. Although they are rather
simple, they do make a huge difference in the quality of the output. As
an example, here is what it generates for the vertex shader in the
Mandelbrot GLSL demo from the Mesa demos repository:
VERT
DCL IN[0]
DCL IN[1]
DCL IN[2]
DCL OUT[0], POSITION
DCL OUT[1], GENERIC[10]
DCL OUT[2], GENERIC[11]
DCL CONST[0..14]
DCL TEMP[0..4]
IMM FLT32 { 2., 0., -0.5000, 5.}
0: MUL TEMP[0], CONST[4], IN[0].
1: MAD TEMP[0], CONST[5], IN[0]., TEMP[0]
2: MAD TEMP[0], CONST[6], IN[0]., TEMP[0]
3: MAD TEMP[0], CONST[7], IN[0]., TEMP[0]
4: MUL TEMP[1].xyz, CONST[12].xyzz, IN[1].
5: MAD TEMP[1], CONST[13].xyzz, IN[1]., TEMP[1].xyzz
6: MAD TEMP[1], CONST[14].xyzz, IN[1]., TEMP[1].xyzz
7: DP3 TEMP[2].x, TEMP[1].xyzz, TEMP[1].xyzz
8: RSQ TEMP[2].x, TEMP[2].
9: MUL TEMP[1].xyz, TEMP[1].xyzz, TEMP[2].
10: ADD TEMP[2].xyz, CONST[3].xyzz, -TEMP[0].xyzz
11: DP3 TEMP[3].x, TEMP[2].xyzz, TEMP[2].xyzz
12: RSQ TEMP[3].x, TEMP[3].
13: MUL TEMP[2].xyz, TEMP[2].xyzz, TEMP[3].
14: MOV TEMP[3].xyz, -TEMP[2].xyzx
15: MOV TEMP[0].xyz, -TEMP[0].xyzx
16: DP3 TEMP[4].x, TEMP[1].xyzz, TEMP[3].xyzz
17: MUL TEMP[4].xyz, TEMP[4]., TEMP[1].xyzz
18: MUL TEMP[4].xyz, IMM[0]., TEMP[4].xyzz
19: ADD TEMP[3].xyz, TEMP[3].xyzz, -TEMP[4].xyzz
20: DP3 TEMP[4].x, TEMP[0].xyzz, TEMP[0].xyzz
21: RSQ TEMP[4].x, TEMP[4].
22: MUL TEMP[0].xyz, TEMP[0].xyzz, TEMP[4].
23: DP3 TEMP[0].x, TEMP[3].xyzz, TEMP[0].xyzz
24: MAX TEMP[0].x, TEMP[0]., IMM[0].
25: POW TEMP[0].x, TEMP[0]., CONST[0].
26: DP3 TEMP[1].x, TEMP[2].xyzz, TEMP[1].xyzz
27: MAX TEMP[1].x, TEMP[1]., IMM[0].
28: MUL TEMP[1].x, CONST[1]., TEMP[1].
29: MAD TEMP[0], CONST[2]., TEMP[0]., TEMP[1].
30: MOV OUT[2], TEMP[0].
31: ADD TEMP[0], IN[2], IMM[0].
32: MUL TEMP[0].xyz, TEMP[0].xyzz, IMM[0].
33: MOV OUT[1].xyz, TEMP[0].xyzx
34: MUL TEMP[0], CONST[8], IN[0].
35: MAD TEMP[0], CONST[9], IN[0]., TEMP[0]
36: MAD
