[Mesa-dev] [Bug 34321] The ARB_fragment_program subset of ARB_draw_buffers not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=34321 Marek Olšák changed: What|Removed |Added CC||i...@freedesktop.org -- 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 34321] New: The ARB_fragment_program subset of ARB_draw_buffers not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=34321 Summary: The ARB_fragment_program subset of ARB_draw_buffers not implemented Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: mar...@gmail.com Hi, I have noticed that the parser for ARB_vertex/fragment_program doesn't implement ARB_draw_buffers. result.color[n] should be allowed if "OPTION ARB_draw_buffers;" is specified. However, when I try to use it like this: > MOV result.color[0], fragment.texcoord[0]; I get this message: > Compiler Error (pos=46 line=-1): line 3, char 17: error: syntax error, > unexpected '[', expecting ',' I was looking at the code of the parser, but I don't understand a thing in it. This bug can be reproduced with: piglit/arb_color_buffer_float-mrt softpipe with ARB_color_buffer_float and ARB_texture_float support, which is required for the piglit test, can be found in this branch: http://cgit.freedesktop.org/~mareko/mesa/?h=floating2 -- 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] util: fix DXT1 RGBA texture compression if the source color is (0, 0, 0, 0)
Ideally we should fix this in libtxc_dxtn, but there is no central
repository for that library, no versioning, and no official releases, and I
am pretty sure that nobody would update that lib just to get this fix.
Putting this fix in Mesa ensures that it will find its way to users, which
is important.
Marek
On Wed, Feb 16, 2011 at 4:18 AM, Marek Olšák wrote:
> This is a workaround for a bug in libtxc_dxtn.
>
> Fixes:
> - piglit/GL_EXT_texture_compression_s3tc/fbo-generatemipmap-formats
> ---
> src/gallium/auxiliary/util/u_format_s3tc.c | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
> b/src/gallium/auxiliary/util/u_format_s3tc.c
> index bb989c2..31288e3 100644
> --- a/src/gallium/auxiliary/util/u_format_s3tc.c
> +++ b/src/gallium/auxiliary/util/u_format_s3tc.c
> @@ -416,8 +416,20 @@ util_format_dxt1_rgba_pack_rgba_8unorm(uint8_t
> *dst_row, unsigned dst_stride,
> uint8_t tmp[4][4][4]; /* [bh][bw][comps] */
> for(j = 0; j < bh; ++j) {
> for(i = 0; i < bw; ++i) {
> - for(k = 0; k < comps; ++k) {
> - tmp[j][i][k] = src[(y + j)*src_stride/sizeof(*src) + (x
> + i)*comps + k];
> + const uint8_t *srcp = &src[(y + j)*src_stride/sizeof(*src)
> + (x + i)*comps];
> + /* Workaround for a bug in libtxc_dxtn.
> +* If the color is (0,0,0,0), it is compressed as
> (0,0,0,1),
> +* which is incorrect. Any other (x,y,z,0) color is
> compressed
> +* correctly as (0,0,0,0), so let's use (1,0,0,0). */
> + if (srcp[0] == 0 && srcp[1] == 0 && srcp[2] == 0 && srcp[3]
> == 0) {
> + tmp[j][i][0] = 255;
> + tmp[j][i][1] = 0;
> + tmp[j][i][2] = 0;
> + tmp[j][i][3] = 0;
> + } else {
> + for(k = 0; k < comps; ++k) {
> + tmp[j][i][k] = srcp[k];
> + }
>}
> }
> }
> --
> 1.7.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: fix DXT1 RGBA texture compression if the source color is (0, 0, 0, 0)
This is a workaround for a bug in libtxc_dxtn.
Fixes:
- piglit/GL_EXT_texture_compression_s3tc/fbo-generatemipmap-formats
---
src/gallium/auxiliary/util/u_format_s3tc.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
b/src/gallium/auxiliary/util/u_format_s3tc.c
index bb989c2..31288e3 100644
--- a/src/gallium/auxiliary/util/u_format_s3tc.c
+++ b/src/gallium/auxiliary/util/u_format_s3tc.c
@@ -416,8 +416,20 @@ util_format_dxt1_rgba_pack_rgba_8unorm(uint8_t *dst_row,
unsigned dst_stride,
uint8_t tmp[4][4][4]; /* [bh][bw][comps] */
for(j = 0; j < bh; ++j) {
for(i = 0; i < bw; ++i) {
- for(k = 0; k < comps; ++k) {
- tmp[j][i][k] = src[(y + j)*src_stride/sizeof(*src) + (x +
i)*comps + k];
+ const uint8_t *srcp = &src[(y + j)*src_stride/sizeof(*src) + (x
+ i)*comps];
+ /* Workaround for a bug in libtxc_dxtn.
+* If the color is (0,0,0,0), it is compressed as (0,0,0,1),
+* which is incorrect. Any other (x,y,z,0) color is compressed
+* correctly as (0,0,0,0), so let's use (1,0,0,0). */
+ if (srcp[0] == 0 && srcp[1] == 0 && srcp[2] == 0 && srcp[3] ==
0) {
+ tmp[j][i][0] = 255;
+ tmp[j][i][1] = 0;
+ tmp[j][i][2] = 0;
+ tmp[j][i][3] = 0;
+ } else {
+ for(k = 0; k < comps; ++k) {
+ tmp[j][i][k] = srcp[k];
+ }
}
}
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tnl: Add support for datatype GL_FIXED in vertex arrays
On Tue, Feb 15, 2011 at 1:05 PM, Chad Versace wrote:
> On 02/14/2011 09:08 PM, Eric Anholt wrote:
>> Don't suppose we have a testcase for these? It could go easily in the
>> ARB_ES2_compat directory without needing new framework stuff.
>
> Just wrote a test case in ARB_ES2_compat, and encountered problems. The
> GL_FIXED enum is not a valid type for glVertexAttribPointer, even though
> ARB_ES2_compat is advertised. Hmm... I'll look into that.
This is probably it:
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index cfed4b5..610a066 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -128,8 +128,11 @@ update_array(struct gl_context *ctx,
GLsizei elementSize;
GLenum format = GL_RGBA;
- if (ctx->API != API_OPENGLES && ctx->API != API_OPENGLES2) {
- /* fixed point arrays / data is only allowed with OpenGL ES 1.x/2.0 */
+ if (ctx->API != API_OPENGLES && ctx->API != API_OPENGLES2 &&
+ !ctx->Extensions.ES2_compatibility) {
+ /* fixed point arrays / data is only allowed with OpenGL ES 1.x/2.0
+ * or GL_ARB_ES2_compatibility.
+ */
legalTypesMask &= ~FIXED_BIT;
}
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tnl: Add support for datatype GL_FIXED in vertex arrays
On 02/14/2011 09:08 PM, Eric Anholt wrote: > Don't suppose we have a testcase for these? It could go easily in the > ARB_ES2_compat directory without needing new framework stuff. Just wrote a test case in ARB_ES2_compat, and encountered problems. The GL_FIXED enum is not a valid type for glVertexAttribPointer, even though ARB_ES2_compat is advertised. Hmm... I'll look into that. -- Chad Versace c...@chad-versace.us ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tnl: Add support for datatype GL_FIXED in vertex arrays
On Tue, 15 Feb 2011 14:44:34 +0800, Shuang He wrote: > On 2011/2/15 13:08, Eric Anholt wrote: > > On Tue, 8 Feb 2011 14:30:55 -0800, Chad Versace > > wrote: > >> Before populating the vertex buffer attribute pointer (VB->AttribPtr[]), > >> convert vertex data in GL_FIXED format to GL_FLOAT. > >> > >> Fixes bug: http://bugs.freedesktop.org/show_bug.cgi?id=34047 > > Don't suppose we have a testcase for these? It could go easily in the > > ARB_ES2_compat directory without needing new framework stuff. > > Does this mean, we don't need infrastructure to support OpenGL ES 2.0 > for piglit anymore? No, we need infrastructure because we also want to test GLES 2.0. pgprYCN5lxDiF.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Fix RGB10_A2 format handling
I've tested and pushed your patch from IRC. Thanks! On Mon, Feb 14, 2011 at 12:07 PM, Fabian Bieler wrote: > This patch fixes the fbo/fbo-clear-formats piglit test. > > As PIPE_FORMAT_B10G10R10A2_UNORM is the only format the mesa state tracker > uses, this is the only format I actualy tested. > > ___ > 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 4/6] gallium: remove pipe_vertex_buffer::max_index
On Mon, 2011-02-14 at 11:04 -0800, Marek Olšák wrote: > On Mon, Feb 14, 2011 at 6:58 PM, José Fonseca > mailto:jfons...@vmware.com>> wrote: > Marek, > > I'm OK with removing pipe_vertex_buffer::max_index but there is a bit > more work involved, as they are not really equivalent in the guarantees. > > pipe_vertex_buffer::max_index is an attribute of the vertex buffer -- it > describe the max index that can be fetch from the buffer without running > into a buffer overflow. It is an hard limit -- it must be set > accurately by the state tracker or crashes will occur. It can be > removed because it can be derived from the vertex element size, vertex > element stride, vertex buffer offset, and vertex buffer size. > > pipe_draw_info::max_index is an attribute of the index buffer: it > describes the maximum index in the index buffer. It is an hint -- there > may be higher indices in the index buffer, and if so it is OK for the > driver to ignore those vertices, but it should not crash with a buffer > overflow. > > Therefore, in order to safely remove pipe_vertex_buffer::max_index, we > should compute the max_index inside the draw module / pipe drivers, and > ensure vertices with higher indices will never be removed. > > There are a few places in this patch where you replace > pipe_vertex_buffer::max_index with ~0 or no checks, which means that > places which where previous robust to pipe_draw_info::max_index == ~0 > and bogus indices will now start crashing. > > You're right in theory. In practice, pipe_vertex_buffer::max_index was really > derived from the value which is put in pipe_draw_info::max_index and was > correctly initialized for user buffers only. It was set to ~0 for hardware > buffers. Moreover, it could also be computed with: > > pipe_vertex_buffer::max_index = (pipe_resource::width0 - > pipe_vertex_buffer::buffer_offset) / pipe_vertex_buffer::stride - 1 > > So it was already redundant. Basically, pipe_resource::width0 is also > redundant for user buffers, because it is actually computed from > pipe_draw_info::max_index too. It's all logical because the index bounds are > the only info we have about user buffers and we compute all the other > properties from it. This is how width0 is computed: > > pipe_resource::width0 = (pipe_draw_info::max_index + 1) * > pipe_vertex_buffer::stride; > > Now we substitute width0 in the first formula: > > pipe_vertex_buffer::max_index = ((pipe_draw_info::max_index + 1) * > pipe_vertex_buffer::stride - pipe_vertex_buffer::buffer_offset) / > pipe_vertex_buffer::stride - 1 > > > If we examine the state tracker code, we'll notice that buffer_offset is > always 0 for user buffers. After simplification, we get this: > > pipe_vertex_buffer::max_index = pipe_draw_info::max_index > > And that's the whole story. That said, I'd like not to call > set_vertex_buffers only to update max_index if I can get the same info from > pipe_draw_info. Because pipe_vertex_buffer::max_index was really the maximum > index value in the index buffer, we don't need to clamp anything when we > fetch vertices, the clamping would basically do nothing. That's why I removed > the clamping in Draw and put ~0 in the translate::run parameter and in > several other places. > > Does this explanation justify all of my changes in the patch to you? As I said, I'm perfectly fine with the removal of max_index. Mesa state tracker may not have been doing the right thing before. It should have been max_index = (pipe_vertex_buffer::size - pipe_vertex_buffer::buffer_offset - util_format_size(vertex_element->format)) / pipe_vertex_buffer::stride + 1 this is the logic that needs to be reinstated in the draw module to prevent buffer overflows spite bogus indices. But no sweat -- I have a few related draw changes on the pipe and I can easily do this. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
> No need to use command line to build. See > http://www.scons.org/wiki/IDEIntegration You are correct, it is possible to build from within Visual Studio but, this solution only executes the scons command. Of course what I'm after is full integration (editor, project source tree, debugging, profiling etc.). Brede On Tue, Feb 15, 2011 at 10:25 AM, José Fonseca wrote: > On Mon, 2011-02-14 at 15:13 -0800, Brede Johansen wrote: >> Hi, >> >> I have made VS2008 project and solution files based on the scons >> files. I have also included generation of necessary source files from >> python as part of the build. This also works in VS2010. >> My requirement was to get OpenGL software rendering to work so it's >> not tested for other configurations. I also had to make small changes >> to the source code, like casting void pointers to the proper type >> (malloc). >> >> > The MSVC project files for Mesa haven't been maintained in a while. >> > They'll be removed in the next Mesa release. Instead, take a look at >> > the instructions for building with scons. >> >> This is sad news for me and probably a few others on the Windows >> platform. Most of us are used to writing code and debug inside Visual >> Studio and would be pretty helpless working from the command line. >> In December I tried to submit the project and solution files to >> mesa-user as an attachment but the post was to big and I didn't have >> the time to follow up. Btw. git is new territory for me. > > No need to use command line to build. See > http://www.scons.org/wiki/IDEIntegration > > Jose > >> >> >> >> On Mon, Feb 14, 2011 at 3:36 PM, Brian Paul wrote: >> > On Fri, Feb 11, 2011 at 11:31 AM, Yahya H. Mirza >> > wrote: >> >> Hi All, >> >> >> >> >> >> >> >> I’ve been trying to build Mesa 7.10 on Windows 7 / Visual Studio 2010 and >> >> I >> >> have been having some problems. >> >> >> >> >> >> >> >> When I opened >> >> >> >> \windows\VC8\mesa\mesa.sln, it was automatically converted to VS2010. >> >> >> >> >> >> >> >> When I tried to build the various projects there were a number of problems >> >> including a number of misconfigured build directories. >> >> >> >> >> >> >> >> Additionally, when building the mesa project in VS2010, it has trouble >> >> finding a path for building “predefined shaders”. >> >> >> >> >> >> >> >> Finally, the “glsl_apps_compile” project seems to be out of date. >> >> >> >> >> >> >> >> Is there an updated version of this solution file for Mesa7.10 / VS2010, >> >> or >> >> has anyone successfully built Mesa7.10 with CMAKE? >> >> >> >> >> >> >> >> Any suggestions on successfully building Mesa7.10 for Windows7 / VS2010 >> >> would be greatly appreciated. >> > >> > The MSVC project files for Mesa haven't been maintained in a while. >> > They'll be removed in the next Mesa release. Instead, take a look at >> > the instructions for building with scons. >> > >> > -Brian >> > ___ >> > 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 > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
Hi, 2011/2/15 Zack Rusin : > [...] > replace everything we have right now. the fact that piglit and our demos > already use it make it even easier. the build system to rule them all. > > unfortunately Jose tried it and the issue was that cmake doesn't support > convinenice libraries which mesa uses quite extensively and there was no > decent way of making it work without recompiling the same file number of times > (not a workable solution from a development point of view). so as it stands > scons is the "official" way of building on windows. CMake devs regularly claim that they do not support convenience libraries. From my point of view cmake supports the most important feature of convenience libraries through static libraries. That is dependency tracking. We use that feature extensively, and so far it has not failed for us in the last two years. But I am not 100% sure what libtool does additionally to dependency tracking. regards Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
Matt Turner writes: > Although, after cmake, if we just added an imake build system, I think > we'd have everything covered. I'm not sure it's possible to run out of build systems ... pretty much everybody has written one! -miles -- Saa, shall we dance? (from a dance-class advertisement) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
On Mon, 2011-02-14 at 15:13 -0800, Brede Johansen wrote: > Hi, > > I have made VS2008 project and solution files based on the scons > files. I have also included generation of necessary source files from > python as part of the build. This also works in VS2010. > My requirement was to get OpenGL software rendering to work so it's > not tested for other configurations. I also had to make small changes > to the source code, like casting void pointers to the proper type > (malloc). > > > The MSVC project files for Mesa haven't been maintained in a while. > > They'll be removed in the next Mesa release. Instead, take a look at > > the instructions for building with scons. > > This is sad news for me and probably a few others on the Windows > platform. Most of us are used to writing code and debug inside Visual > Studio and would be pretty helpless working from the command line. > In December I tried to submit the project and solution files to > mesa-user as an attachment but the post was to big and I didn't have > the time to follow up. Btw. git is new territory for me. No need to use command line to build. See http://www.scons.org/wiki/IDEIntegration Jose > > > > On Mon, Feb 14, 2011 at 3:36 PM, Brian Paul wrote: > > On Fri, Feb 11, 2011 at 11:31 AM, Yahya H. Mirza > > wrote: > >> Hi All, > >> > >> > >> > >> I’ve been trying to build Mesa 7.10 on Windows 7 / Visual Studio 2010 and I > >> have been having some problems. > >> > >> > >> > >> When I opened > >> > >> \windows\VC8\mesa\mesa.sln, it was automatically converted to VS2010. > >> > >> > >> > >> When I tried to build the various projects there were a number of problems > >> including a number of misconfigured build directories. > >> > >> > >> > >> Additionally, when building the mesa project in VS2010, it has trouble > >> finding a path for building “predefined shaders”. > >> > >> > >> > >> Finally, the “glsl_apps_compile” project seems to be out of date. > >> > >> > >> > >> Is there an updated version of this solution file for Mesa7.10 / VS2010, or > >> has anyone successfully built Mesa7.10 with CMAKE? > >> > >> > >> > >> Any suggestions on successfully building Mesa7.10 for Windows7 / VS2010 > >> would be greatly appreciated. > > > > The MSVC project files for Mesa haven't been maintained in a while. > > They'll be removed in the next Mesa release. Instead, take a look at > > the instructions for building with scons. > > > > -Brian > > ___ > > 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
