Re: [Mesa-dev] [PIGLIT, radeonsi] crash in spec/glsl-1.50/execution/geometry/max-input-components fixed
Hello Tom, Tom Stellard schrieb am 19.04.2014 06:37: > On Fri, Apr 18, 2014 at 06:59:37PM +0200, Kai Wasserbäch wrote: >> Tom Stellard schrieb am 16.04.2014 17:07: >>> Here is the branch: >>> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes I noticed, that the patches add a SI_SPILL_V96 instruction and while all others are added to getNumSubRegsForSpillOp() as well as SIInstrInfo::expandPostRAPseudo(), both in lib/Target/R600/SIInstrInfo.cpp, I don't see the V96 case covered. Is this an oversight or am I missing something (entirely possible, since my LLVM knowledge is very limited)? I just thought I bring it up, in case that's something you'd like to fix before pushing it out. > Thanks for tracking this down. I've been trying to find a good test > case for register spilling and this looks like it might be it. Most of > the register spilling bugs come from proprietary games that I don't have > access to. I will try to look at this on Monday. I'm glad I could help. If you know of a specific game, maybe ping me privately and if I have it, I'm willing to test those as well. >> P.S.: Any idea, when the si-spill-fixes branch is going to land upstream? >> > > As soon as I can verify that it is working. Ok, fair enough. ;-) (Just wanted to know how long I've to keep building LLVM myself :-p) Cheers, Kai -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: k...@dev.carbon-project.org signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] llvmpipe: fix clearing of individual color buffers in a fb
Am 19.04.2014 02:02, schrieb Brian Paul:
> Looks good, but some comments below.
>
> On 04/17/2014 04:34 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> GL (3.0) allows you to clear individual color buffers in a fb. In fact
>> for fbs containing both int and float/normalized color buffers this is
>> required (because the clearing values are otherwise undefined if applied
>> to all buffers). The gallium interface was changed a while ago, but
>> llvmpipe
>> ignored it (hence doing such individual clears always resulted in
>> clearing
>> all buffers, plus some assorted asserts due to the mixed fbs).
>> So change the clear command to indicate the buffer to be cleared.
>> Also, because
>> indicating the buffer to be cleared would have made lp_rast_arg_cmd
>> larger
>> which is unacceptable (we're trying to shrink it some day) allocate
>> the clear
>> value in the scene and just pass a pointer.
>> There's several advantages and disadvantages here:
>> + clearing individual buffers works (we could also actually bin such
>> clears now
>> if they'd come through clear_render_target() if the surface is in the
>> current
>> fb, though we didn't do this before for the single rb case and still
>> don't try).
>> + since there's one clear per rb, we do the format conversion in setup
>> rather
>> than per bin. Aside from the (drop in the ocean...) performance
>> advantage this
>> means that clearing to very small values (that is, denormal when
>> converted to
>> the format) should work for small float (fp16 etc.) formats, as the
>> util code
>> couldn't handle it correctly before (because cpu denorms are disabled
>> when
>> executing the bin commands, screwing up the magic conversion and flushing
>> the values to 0, though this was not verified).
>> - there's some overhead for traditional old-style clear-all MRT cases,
>> since
>> there's one rast clear command per rb instead of one for all rbs.
>>
>> This fixes
>> https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D76976&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=y3sw7wM2Q5uQZ5g2gbFobrUxiKtq3QYKvNrg%2FCOHp2o%3D%0A&s=f618c2f64d18f2d0fae410f96dce78a37b6f56b1655d4f99adad81da3c445735.
>>
>> ---
>> src/gallium/drivers/llvmpipe/lp_rast.c | 122 -
>> src/gallium/drivers/llvmpipe/lp_rast.h |8 +-
>> src/gallium/drivers/llvmpipe/lp_scene.c |1 -
>> src/gallium/drivers/llvmpipe/lp_scene.h |1 -
>> src/gallium/drivers/llvmpipe/lp_setup.c | 216
>> ---
>> src/gallium/drivers/llvmpipe/lp_setup_context.h |2 +-
>> 6 files changed, 189 insertions(+), 161 deletions(-)
>>
>> diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
>> b/src/gallium/drivers/llvmpipe/lp_rast.c
>> index 0ae5976..8667a6c 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_rast.c
>> +++ b/src/gallium/drivers/llvmpipe/lp_rast.c
>> @@ -110,25 +110,6 @@ lp_rast_tile_begin(struct lp_rasterizer_task *task,
>>
>>
>> /**
>> - * Examine a framebuffer object to determine if any of the colorbuffers
>> - * use a pure integer format.
>> - * XXX this could be a gallium utility function if useful elsewhere.
>> - */
>> -static boolean
>> -is_fb_pure_integer(const struct pipe_framebuffer_state *fb)
>> -{
>> - unsigned i;
>> - for (i = 0; i < fb->nr_cbufs; i++) {
>> - if (fb->cbufs[i] &&
>> - util_format_is_pure_integer(fb->cbufs[i]->format)) {
>> - return TRUE;
>> - }
>> - }
>> - return FALSE;
>> -}
>> -
>> -
>> -/**
>>* Clear the rasterizer's current color tile.
>>* This is a bin command called during bin processing.
>>* Clear commands always clear all bound layers.
>> @@ -138,81 +119,40 @@ lp_rast_clear_color(struct lp_rasterizer_task
>> *task,
>> const union lp_rast_cmd_arg arg)
>> {
>> const struct lp_scene *scene = task->scene;
>> + unsigned cbuf = arg.clear_rb->cbuf;
>> + union util_color uc;
>> + enum pipe_format format;
>>
>> - if (scene->fb.nr_cbufs) {
>> - unsigned i;
>> - union util_color uc;
>> -
>> - if (is_fb_pure_integer(&scene->fb)) {
>> - /*
>> - * We expect int/uint clear values here, though some APIs
>> - * might disagree (but in any case util_pack_color()
>> - * couldn't handle it)...
>> - */
>> - LP_DBG(DEBUG_RAST, "%s pure int 0x%x,0x%x,0x%x,0x%x\n",
>> __FUNCTION__,
>> -arg.clear_color.ui[0],
>> -arg.clear_color.ui[1],
>> -arg.clear_color.ui[2],
>> -arg.clear_color.ui[3]);
>> -
>> - for (i = 0; i < scene->fb.nr_cbufs; i++) {
>> -enum pipe_format format = scene->fb.cbufs[i]->format;
>> -
>> -if (util_format_is_pure_sint(format)) {
>> - util_format_write_4i(format, arg.clear_color.i, 0,
>> &uc, 0, 0, 0, 1, 1);
>> -}
>> -
[Mesa-dev] Broadcom VideoCore IV
The VideoCore IV GPU has 14 cores: - 2 VPU Cores : Full-blown cores which run the ThreadX RTOS. There is an experimental LLVM port to it and also the VBCC C89 compiler(which has'nt time support so classic benchmarks run indefinitely). The binary blob run on that. 5 GFlops - 12 QPU Cores : 3D cores officially documented by Broadcom and using a tile-mode rendering architecture. The full Android driver for that was open-sourced at the end of February. 24Gflops Questions: Can Gallium3D run with tile-mode rendering architecture ? Is it better using Mesa and the Broadcom shader compiler ? Is it better using the VPU and an adapted LLVMpipe ? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Regressions due to commit 1afe3359258
On Fri, Apr 18, 2014 at 1:35 PM, Jordan Justen
wrote:
> On 2014-04-18 08:46:00, Kenneth Graunke wrote:
>> On 04/18/2014 12:09 AM, Ilia Mirkin wrote:
>> > Hi Ken,
>> >
>> > I just did a bisect looking for the failure that's causing a few
>> > gs-related piglits to fail on nv50, and it came up with the below. Any
>> > ideas? Here are the tests that are failing:
>> >
>> > tests/spec/glsl-1.50/execution/geometry/clip-distance-out-values.shader_test
>> > tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
>> > tests/spec/glsl-1.50/execution/geometry/point-size-out.shader_test
>> > tests/spec/glsl-1.50/execution/geometry/primitive-id-out.shader_test
>> > tests/spec/glsl-1.50/execution/gs-redeclares-both-pervertex-blocks.shader_test
>> > tests/spec/glsl-1.50/execution/interface-vs-named-to-gs-array.shader_test
>> > tests/spec/glsl-1.50/execution/redeclare-pervertex-out-subset-gs.shader_test
>> > tests/spec/glsl-1.50/execution/redeclare-pervertex-subset-vs-to-gs.shader_test
>> >
>> > 1afe3359258a9e89b62c8638761f52d78f6d1cbc is the first bad commit
>> > commit 1afe3359258a9e89b62c8638761f52d78f6d1cbc
>> > Author: Kenneth Graunke
>> > Date: Thu Mar 20 11:53:16 2014 -0700
>> >
>> > mesa: In core profile, refuse to draw unless a VAO is bound.
>> >
>> > Core profile requires a non-default VAO to be bound. Currently, calls
>> > to glVertexAttribPointer raise INVALID_OPERATION unless a VAO is bound,
>> > and we never actually get any vertex data set. Trying to draw without
>> > any vertex data can only cause problems. In i965, it causes a crash.
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76400
>> > Signed-off-by: Kenneth Graunke
>> > Reviewed-by: Ian Romanick
>> > Cc: mesa-sta...@lists.freedesktop.org
>> >
>> > Reverting this commit on top of master makes it work again. I have no
>> > idea whether it's the tests/piglit infra that are wrong, or if it's
>> > the commit that's wrong, but wanted to raise the issue. This still
>> > happens with the (almost-)latest piglit (latest doesn't compile due to
>> > EGL stuff...)
>> >
>> > Let me know if you'd like any additional info.
>> >
>> > Thanks,
>> >
>> > -ilia
>>
>> Yeah, we're seeing those too. I believe the commit is wrong: with
>> geometry shaders, you can just generate vertices using a GS program and
>> not actually ever upload any vertex data. At which point, you probably
>> don't need a VAO. I haven't double checked the rules, though.
>
> I'm not sure spec-wise, but I found that nvidia requires a VAO, even
> without vertex data. (See piglit b28cdc88, but note that this commit
> caused some other issues and was reverted in c20596b8).
So this is what the spec says (GL4.4, page 322/323):
An INVALID_OPERATION error is generated by any commands which
modify, draw from, or query vertex array state when no vertex array is bound.
This occurs in the initial GL state, and may occur as a result of
BindVertexArray
or a side effect of DeleteVertexArrays.
And this is what one of the piglits in question does:
[test]
clear color 0.0 0.0 0.0 0.0
clear
draw arrays GL_TRIANGLES 0 3
probe all rgba 0.0 1.0 0.0 1.0
and this is what shader_runner does:
if (link_ok && vertex_data_start != NULL) {
program_must_be_in_use();
if (gl_version.num >= 31) {
GLuint vao;
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
}
num_vbo_rows = setup_vbo_from_text(prog, vertex_data_start,
vertex_data_end);
vbo_present = true;
}
So what's the right move here? I think it might actually be to
change shader_runner to always generate a VAO even if there is no
vertex data. I haven't checked, but I suspect it would also fix the
piglit failures, and leave the current mesa code in place.
Thoughts?
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: Add GetSyncValuesCHROMIUM extension.
On Fri, Apr 18, 2014 at 05:30:02PM -0700, Ian Romanick wrote: > On 04/18/2014 05:07 PM, Jamey Sharp wrote: > > On Fri, Apr 18, 2014 at 4:49 PM, Ian Romanick wrote: > >> On 04/18/2014 03:37 PM, Sarah Sharp wrote: > If you use the unchecked > > variant of the request, then the error is placed in the event queue; > > if you're using Xlib, then by default it will be abort()ing your > > client as soon as it pulls the error out of the event queue. > > Unless the client has an error handler, right? Even if the client does have an event handler, I don't believe it should receive error events from Mesa's EGL internals. If the error originates in EGL, then EGL should swallow it and bubble the error up as a standard EGL error. If glXCupcake() places an X error into Xlib's event queue, no application should be surprised. GLX is an Xlib API, afterall. But, if eglCupcake() places an error into Xlib's event queue, that just feels wrong. I'm in favor of s/_unchecked//g as Jamey suggests. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: Add GetSyncValuesCHROMIUM extension.
On Fri, Apr 18, 2014 at 06:19:06PM -0700, Sarah Sharp wrote: > [I missed Chad on the original Cc somehow; hopefully he can find the > original mails.] I have some comments too. Some of my comments conflict with Ian's, and also conflict with advice I previously gave you (sorry). > On Fri, Apr 18, 2014 at 04:49:43PM -0700, Ian Romanick wrote: > > On 04/18/2014 03:37 PM, Sarah Sharp wrote: > > > Chromium defined a new GL extension (that isn't registered with Khronos). > > > We need to add an EGL extension for it, so we can migrate ChromeOS on > > > Intel systems to use EGL instead of GLX. > > > > > > http://git.chromium.org/gitweb/?p=chromium/src/third_party/khronos.git;a=commitdiff;h=27cbfdab35c601f70aa150581ad1448d0401f447 > > > > > > The extension is similar to the GLX extension OML_sync_control, but only > > > defines one function, eglGetSyncValuesCHROMIUM, which is equivalent to > > > glXGetSyncValuesOML. > > > > > > http://www.opengl.org/registry/specs/OML/glx_sync_control.txt > > > > > > One open question: > > > > > > I've used the normal (error checked) version of xcb_dri2_get_msc. The > > > GLX implementation of glXGetSyncValuesOML uses the unchecked version, > > > but I'm not convinced it's necessary. > > > > > > I talked to Jamey Sharp, and he doesn't understand why most of Mesa > > > calls the unchecked versions of XCB functions. He thought most > > > developers would want to use the normal (checked) versions, since the > > > unchecked versions may segfault on errors. Mesa can always call the > > > checked version, but ignore the error that's set, so it doesn't have to > > > use the unchecked version. > > > > When I added some XCB code to Mesa a couple years ago, it wasn't > > completely clear to me what the difference was between the checked and > > unchecked versions. See 6ccda72 and 588042a. My recollection was that > > the _checked versions returned a cookie that you had to do something > > with. For a bunch of the cases, I think we don't want to do the extra > > bookkeeping (or we don't want the extra opportunity for a memory) leak. > > > > Is there more difference than I know? > > > > I have 3 additional comments in the code below. > > Thanks for the review Ian! > > > > I talked to Kristen Høgsberg, who added most of the Mesa XCB calls, and > > > he said he copied the style from Chris Wilson. If using the unchecked > > > versions isn't required, we should look into moving the XCB calls in > > > Mesa to the normal checked versions. Otherwise people will just keep > > > copy-pasting the unchecked versions around. > > > > > > Signed-off-by: Sarah Sharp > > > Cc: Chad Versace > > > Cc: Kristian Høgsberg > > > Cc: Jamey Sharp > > > --- > > > include/EGL/eglext.h | 10 ++ > > > src/egl/drivers/dri2/egl_dri2.c | 15 +++ > > > src/egl/drivers/dri2/egl_dri2.h | 4 > > > src/egl/drivers/dri2/egl_dri2_fallbacks.h | 8 > > > src/egl/drivers/dri2/platform_android.c | 1 + > > > src/egl/drivers/dri2/platform_drm.c | 1 + > > > src/egl/drivers/dri2/platform_wayland.c | 1 + > > > src/egl/drivers/dri2/platform_x11.c | 27 > > > +++ > > > src/egl/main/eglapi.c | 27 > > > +++ > > > src/egl/main/eglapi.h | 7 +++ > > > src/egl/main/egldisplay.h | 1 + > > > src/egl/main/eglmisc.c| 1 + > > > 12 files changed, 103 insertions(+) > > > > > > diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h > > > index 243da4a..097ad68 100644 > > > --- a/include/EGL/eglext.h > > > +++ b/include/EGL/eglext.h > > > @@ -588,6 +588,16 @@ EGLAPI EGLBoolean EGLAPIENTRY eglPostSubBufferNV > > > (EGLDisplay dpy, EGLSurface sur > > > #endif > > > #endif /* EGL_NV_post_sub_buffer */ > > > > > > +#if KHRONOS_SUPPORT_INT64 /* EGLSyncControlCHROMIUM requires 64-bit > > > uint support */ > > > +#ifndef EGL_CHROMIUM_sync_control > > > +#define EGL_CHROMIUM_sync_control 1 > > > +#ifdef EGL_EGLEXT_PROTOTYPES > > > +EGLAPI EGLBoolean EGLAPIENTRY eglGetSyncValuesCHROMIUM(EGLDisplay dpy, > > > EGLSurface surface, EGLuint64KHR *ust, EGLuint64KHR *msc, EGLuint64KHR > > > *sbc); > > > +#endif /* EGL_EGLEXT_PROTOTYPES */ > > > +typedef EGLBoolean (EGLAPIENTRYP > > > PFNEGLGETSYNCVALUESCHROMIUMPROC)(EGLDisplay dpy, EGLSurface surface, > > > EGLuint64KHR *ust, EGLuint64KHR *msc, EGLuint64KHR *sbc); > > > +#endif > > > +#endif > > > + > > > > It's very annoying that this extension isn't in the Khronos registry. > > The problem is we periodically import new versions of eglext.h from the > > registry. If the next import doesn't have this extension, this code > > will be lost. > > > > I think we need to put this in eglmesaext.h instead. > > Ok, will do. As Ian said, this shouldn't go into eglext.h. But, I don't think it should go into eglmesaext.h either. To prevent any conflict of
Re: [Mesa-dev] Regressions due to commit 1afe3359258
On Sat, Apr 19, 2014 at 10:03 AM, Ilia Mirkin wrote:
> On Fri, Apr 18, 2014 at 1:35 PM, Jordan Justen
> wrote:
>> On 2014-04-18 08:46:00, Kenneth Graunke wrote:
>>> On 04/18/2014 12:09 AM, Ilia Mirkin wrote:
>>> > Hi Ken,
>>> >
>>> > I just did a bisect looking for the failure that's causing a few
>>> > gs-related piglits to fail on nv50, and it came up with the below. Any
>>> > ideas? Here are the tests that are failing:
>>> >
>>> > tests/spec/glsl-1.50/execution/geometry/clip-distance-out-values.shader_test
>>> > tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
>>> > tests/spec/glsl-1.50/execution/geometry/point-size-out.shader_test
>>> > tests/spec/glsl-1.50/execution/geometry/primitive-id-out.shader_test
>>> > tests/spec/glsl-1.50/execution/gs-redeclares-both-pervertex-blocks.shader_test
>>> > tests/spec/glsl-1.50/execution/interface-vs-named-to-gs-array.shader_test
>>> > tests/spec/glsl-1.50/execution/redeclare-pervertex-out-subset-gs.shader_test
>>> > tests/spec/glsl-1.50/execution/redeclare-pervertex-subset-vs-to-gs.shader_test
>>> >
>>> > 1afe3359258a9e89b62c8638761f52d78f6d1cbc is the first bad commit
>>> > commit 1afe3359258a9e89b62c8638761f52d78f6d1cbc
>>> > Author: Kenneth Graunke
>>> > Date: Thu Mar 20 11:53:16 2014 -0700
>>> >
>>> > mesa: In core profile, refuse to draw unless a VAO is bound.
>>> >
>>> > Core profile requires a non-default VAO to be bound. Currently, calls
>>> > to glVertexAttribPointer raise INVALID_OPERATION unless a VAO is
>>> > bound,
>>> > and we never actually get any vertex data set. Trying to draw without
>>> > any vertex data can only cause problems. In i965, it causes a crash.
>>> >
>>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76400
>>> > Signed-off-by: Kenneth Graunke
>>> > Reviewed-by: Ian Romanick
>>> > Cc: mesa-sta...@lists.freedesktop.org
>>> >
>>> > Reverting this commit on top of master makes it work again. I have no
>>> > idea whether it's the tests/piglit infra that are wrong, or if it's
>>> > the commit that's wrong, but wanted to raise the issue. This still
>>> > happens with the (almost-)latest piglit (latest doesn't compile due to
>>> > EGL stuff...)
>>> >
>>> > Let me know if you'd like any additional info.
>>> >
>>> > Thanks,
>>> >
>>> > -ilia
>>>
>>> Yeah, we're seeing those too. I believe the commit is wrong: with
>>> geometry shaders, you can just generate vertices using a GS program and
>>> not actually ever upload any vertex data. At which point, you probably
>>> don't need a VAO. I haven't double checked the rules, though.
>>
>> I'm not sure spec-wise, but I found that nvidia requires a VAO, even
>> without vertex data. (See piglit b28cdc88, but note that this commit
>> caused some other issues and was reverted in c20596b8).
>
> So this is what the spec says (GL4.4, page 322/323):
>
> An INVALID_OPERATION error is generated by any commands which
> modify, draw from, or query vertex array state when no vertex array is bound.
> This occurs in the initial GL state, and may occur as a result of
> BindVertexArray
> or a side effect of DeleteVertexArrays.
>
> And this is what one of the piglits in question does:
>
> [test]
> clear color 0.0 0.0 0.0 0.0
> clear
> draw arrays GL_TRIANGLES 0 3
> probe all rgba 0.0 1.0 0.0 1.0
>
> and this is what shader_runner does:
>
> if (link_ok && vertex_data_start != NULL) {
> program_must_be_in_use();
> if (gl_version.num >= 31) {
> GLuint vao;
>
> glGenVertexArrays(1, &vao);
> glBindVertexArray(vao);
> }
>
> num_vbo_rows = setup_vbo_from_text(prog, vertex_data_start,
> vertex_data_end);
> vbo_present = true;
> }
>
> So what's the right move here? I think it might actually be to
> change shader_runner to always generate a VAO even if there is no
> vertex data.
Right, and that is what I did in piglit b28cdc88, but:
http://lists.freedesktop.org/archives/piglit/2014-April/010179.html
caused me to revert it (c20596b8).
Brian pointed out tests/shaders/glsl-fs-any.shader_test as an example
that failed on nvidia with b28cdc88.
Yet, b28cdc88 fixes
tests/spec/glsl-1.50/execution/geometry/point-size-out.shader_test on
nvidia, so hopefully there is a way to make nvidia happy on both
tests. :)
-Jordan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] fix GetStringi error message with correct name function
Signed-off-by: Benjamin Bellec --- src/mesa/main/getstring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c index 3ac62d4..1ac92e2 100644 --- a/src/mesa/main/getstring.c +++ b/src/mesa/main/getstring.c @@ -166,7 +166,7 @@ _mesa_GetStringi(GLenum name, GLuint index) } return _mesa_get_enabled_extension(ctx, index); default: - _mesa_error( ctx, GL_INVALID_ENUM, "glGetString" ); + _mesa_error( ctx, GL_INVALID_ENUM, "glGetStringi" ); return (const GLubyte *) 0; } } -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] fix GetStringi error message with correct name function
I forgot to cc the stable mailing list for this patch. 2014-04-19 21:05 GMT+02:00 Benjamin Bellec : > > Signed-off-by: Benjamin Bellec > --- > src/mesa/main/getstring.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c > index 3ac62d4..1ac92e2 100644 > --- a/src/mesa/main/getstring.c > +++ b/src/mesa/main/getstring.c > @@ -166,7 +166,7 @@ _mesa_GetStringi(GLenum name, GLuint index) >} >return _mesa_get_enabled_extension(ctx, index); > default: > - _mesa_error( ctx, GL_INVALID_ENUM, "glGetString" ); > + _mesa_error( ctx, GL_INVALID_ENUM, "glGetStringi" ); >return (const GLubyte *) 0; > } > } > -- > 1.8.1.4 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: Add GetSyncValuesCHROMIUM extension.
On Fri, Apr 18, 2014 at 3:37 PM, Sarah Sharp
wrote:
> Chromium defined a new GL extension (that isn't registered with Khronos).
>
This here is the problem IMO. I'll see next week what we can do about
pushing for this to become a registered extension. Intel would be our 2nd
implementation, so I think we have enough support at this point.
Stéphane
> We need to add an EGL extension for it, so we can migrate ChromeOS on
> Intel systems to use EGL instead of GLX.
>
>
> http://git.chromium.org/gitweb/?p=chromium/src/third_party/khronos.git;a=commitdiff;h=27cbfdab35c601f70aa150581ad1448d0401f447
>
> The extension is similar to the GLX extension OML_sync_control, but only
> defines one function, eglGetSyncValuesCHROMIUM, which is equivalent to
> glXGetSyncValuesOML.
>
> http://www.opengl.org/registry/specs/OML/glx_sync_control.txt
>
> One open question:
>
> I've used the normal (error checked) version of xcb_dri2_get_msc. The
> GLX implementation of glXGetSyncValuesOML uses the unchecked version,
> but I'm not convinced it's necessary.
>
> I talked to Jamey Sharp, and he doesn't understand why most of Mesa
> calls the unchecked versions of XCB functions. He thought most
> developers would want to use the normal (checked) versions, since the
> unchecked versions may segfault on errors. Mesa can always call the
> checked version, but ignore the error that's set, so it doesn't have to
> use the unchecked version.
>
> I talked to Kristen Høgsberg, who added most of the Mesa XCB calls, and
> he said he copied the style from Chris Wilson. If using the unchecked
> versions isn't required, we should look into moving the XCB calls in
> Mesa to the normal checked versions. Otherwise people will just keep
> copy-pasting the unchecked versions around.
>
> Signed-off-by: Sarah Sharp
> Cc: Chad Versace
> Cc: Kristian Høgsberg
> Cc: Jamey Sharp
> ---
> include/EGL/eglext.h | 10 ++
> src/egl/drivers/dri2/egl_dri2.c | 15 +++
> src/egl/drivers/dri2/egl_dri2.h | 4
> src/egl/drivers/dri2/egl_dri2_fallbacks.h | 8
> src/egl/drivers/dri2/platform_android.c | 1 +
> src/egl/drivers/dri2/platform_drm.c | 1 +
> src/egl/drivers/dri2/platform_wayland.c | 1 +
> src/egl/drivers/dri2/platform_x11.c | 27 +++
> src/egl/main/eglapi.c | 27 +++
> src/egl/main/eglapi.h | 7 +++
> src/egl/main/egldisplay.h | 1 +
> src/egl/main/eglmisc.c| 1 +
> 12 files changed, 103 insertions(+)
>
> diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
> index 243da4a..097ad68 100644
> --- a/include/EGL/eglext.h
> +++ b/include/EGL/eglext.h
> @@ -588,6 +588,16 @@ EGLAPI EGLBoolean EGLAPIENTRY eglPostSubBufferNV
> (EGLDisplay dpy, EGLSurface sur
> #endif
> #endif /* EGL_NV_post_sub_buffer */
>
> +#if KHRONOS_SUPPORT_INT64 /* EGLSyncControlCHROMIUM requires 64-bit
> uint support */
> +#ifndef EGL_CHROMIUM_sync_control
> +#define EGL_CHROMIUM_sync_control 1
> +#ifdef EGL_EGLEXT_PROTOTYPES
> +EGLAPI EGLBoolean EGLAPIENTRY eglGetSyncValuesCHROMIUM(EGLDisplay dpy,
> EGLSurface surface, EGLuint64KHR *ust, EGLuint64KHR *msc, EGLuint64KHR
> *sbc);
> +#endif /* EGL_EGLEXT_PROTOTYPES */
> +typedef EGLBoolean (EGLAPIENTRYP
> PFNEGLGETSYNCVALUESCHROMIUMPROC)(EGLDisplay dpy, EGLSurface surface,
> EGLuint64KHR *ust, EGLuint64KHR *msc, EGLuint64KHR *sbc);
> +#endif
> +#endif
> +
> #ifndef EGL_NV_stream_sync
> #define EGL_NV_stream_sync 1
> #define EGL_SYNC_NEW_FRAME_NV 0x321F
> diff --git a/src/egl/drivers/dri2/egl_dri2.c
> b/src/egl/drivers/dri2/egl_dri2.c
> index dc541ad..df8d9af 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1386,6 +1386,18 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay
> *disp, _EGLContext *ctx,
> }
> #endif
>
> +#ifdef EGL_CHROMIUM_sync_control
> +static EGLBoolean
> +dri2_get_sync_values_chromium(_EGLDisplay *dpy, _EGLSurface *surf,
> + EGLuint64KHR *ust, EGLuint64KHR *msc,
> + EGLuint64KHR *sbc)
> +{
> + struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
> + return dri2_dpy->vtbl->get_sync_values(dpy, surf, ust, msc, sbc);
> +}
> +#endif
> +
> +
> /**
> * Set the error code after a call to
> * dri2_egl_image::dri_image::createImageFromTexture.
> @@ -2177,6 +2189,9 @@ _eglBuiltInDriverDRI2(const char *args)
> dri2_drv->base.API.UnbindWaylandDisplayWL =
> dri2_unbind_wayland_display_wl;
> dri2_drv->base.API.QueryWaylandBufferWL = dri2_query_wayland_buffer_wl;
> #endif
> +#ifdef EGL_CHROMIUM_sync_control
> + dri2_drv->base.API.GetSyncValuesCHROMIUM =
> dri2_get_sync_values_chromium;
> +#endif
>
> dri2_drv->base.Name = "DRI2";
> dri2_drv->base.Unload = dri2_unload;
> diff --git a/src/egl/drivers/dri2/egl_dri2.h
> b/src/egl/drivers/dri2/egl_dri2.h
> ind
Re: [Mesa-dev] [PATCH mesa/mesa] Check for dladdr(), rather than assuming we have it if we have RTLD_DEFAULT
On 17/04/14 11:41, Jon TURNEY wrote: > On 09/04/2014 14:53, Jonathan Gray wrote: >> On Sun, Apr 06, 2014 at 03:30:43PM +0100, Jon TURNEY wrote: >>> Unfortunately, Cygwin defines RTLD_DEFAULT (for glibc compatibility), but >>> can't >>> provide dladdr(), so add a check for dladdr() >>> >>> --- >>> configure.ac | 6 ++ >>> src/mesa/drivers/dri/common/megadriver_stub.c | 7 +++ >>> 2 files changed, 9 insertions(+), 4 deletions(-) >>> >>> diff --git a/configure.ac b/configure.ac >>> index 878b24a..bbbed79 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -480,6 +480,12 @@ AC_CHECK_FUNC([dlopen], [DEFINES="$DEFINES >>> -DHAVE_DLOPEN"], >>> [DEFINES="$DEFINES -DHAVE_DLOPEN"; DLOPEN_LIBS="-ldl"])]) >>> AC_SUBST([DLOPEN_LIBS]) >>> >>> +dnl Check if that library also has dladdr >>> +SAVE_LDFLAGS="$LDFLAGS" >> >> The case here is wrong and won't work as intended unless changed to >> save_LDFLAGS. > > Good catch. > >> Otherwise the patch seems fine, though it will break the scons build till >> those files are updated? > > Updated patch attached with what I think are the appropriate scons runes added > (and sent to the right mailing list this time! :-) ). > Scons seems to have analogous function to AC_CHECK_FUNCS -> CheckFunc. Never used it + not sure if it's worth the extra code considering the use base of scons users. As I doubt that anyone else will review this patch, it might be worth pushing it and working out the issues (if any) as they arise. Planning to do this in the middle of the week. -Emil > > > > ___ > 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 01/16] dri_util: keep __dri2ConfigOptions symbol private
On 05/04/14 02:46, Emil Velikov wrote: > The symbol was added with commit 45e2b51c853(DRI2/GLX: check for > vblank_mode in DRI2 GLX code) but was never used as such according > to git log. > > Possibly it was marked as public due to confusion with > __driConfigOptions which was used for dri1 drivers. > Hi Jesse Do you have an idea if the above assumption stands ? Cheers, -Emil > Cc: Jesse Barnes > Signed-off-by: Emil Velikov > --- > src/mesa/drivers/dri/common/dri_util.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/common/dri_util.c > b/src/mesa/drivers/dri/common/dri_util.c > index aed73c7..9f73a26 100644 > --- a/src/mesa/drivers/dri/common/dri_util.c > +++ b/src/mesa/drivers/dri/common/dri_util.c > @@ -52,7 +52,7 @@ > #include "main/errors.h" > #include "main/macros.h" > > -PUBLIC const char __dri2ConfigOptions[] = > +const char __dri2ConfigOptions[] = > DRI_CONF_BEGIN >DRI_CONF_SECTION_PERFORMANCE > DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_1) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/16] targets/libgl-xlib: hide all the exported symbol mayhem
humble ping
On 05/04/14 02:47, Emil Velikov wrote:
> TODO:
> - properly cleanup all the _glapi* symbols
> - XMesa*
> -- no sign of the header even being distributed
> -- mesa-demos uses it to the point that the relevant code is not compiled
> -- the classic driver (x11) exibits the same issues
>
> Brian,
>
> Do you know of any users of the XMesa* functions outside of mesa-demos ?
> AFAICS we should be safe with dropping PUBLIC although I may have missed
> something. As a follow up someone can cleanup all the mesa-demos code :)
>
> Cc: Brian Paul
> Signed-off-by: Emil Velikov
> ---
> src/gallium/targets/libgl-xlib/Makefile.am| 1 +
> src/gallium/targets/libgl-xlib/libgl-xlib.sym | 6 ++
> 2 files changed, 7 insertions(+)
> create mode 100644 src/gallium/targets/libgl-xlib/libgl-xlib.sym
>
> diff --git a/src/gallium/targets/libgl-xlib/Makefile.am
> b/src/gallium/targets/libgl-xlib/Makefile.am
> index ef3d23e..d284a17 100644
> --- a/src/gallium/targets/libgl-xlib/Makefile.am
> +++ b/src/gallium/targets/libgl-xlib/Makefile.am
> @@ -47,6 +47,7 @@ libGL_la_SOURCES = xlib.c
> libGL_la_LDFLAGS = \
> -no-undefined \
> -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_TINY) \
> +
> -Wl,--version-script=$(top_srcdir)/src/gallium/targets/libgl-xlib/libgl-xlib.sym
> \
> $(GC_SECTIONS) \
> -Wl,--no-undefined
>
> diff --git a/src/gallium/targets/libgl-xlib/libgl-xlib.sym
> b/src/gallium/targets/libgl-xlib/libgl-xlib.sym
> new file mode 100644
> index 000..d6cd23d
> --- /dev/null
> +++ b/src/gallium/targets/libgl-xlib/libgl-xlib.sym
> @@ -0,0 +1,6 @@
> +{
> + global:
> + gl*;
> + local:
> + *;
> +};
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] The way r600g handles shaders that use more than available GPRs
Hello, I realized while playing Diablo III on my machine that some shaders seem to run out of available GPRs using r600g with my Macbook Pro with a HD6750m. If the driver tries to do something to handle this case, but I couldn't find any part inside the code that has to do with "spilling". There are some register related passes in SB, but none seems to be related to possible spilling (anyway, the failing I get is in r600_shader.c:2148 inside "r600_shader_from_tgsi()" which makes shader compiling failing altogether skipping SB). How does r600g handle out of register situations? If it doesn't there are plans to add this? Cheers, Marcello ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] The way r600g handles shaders that use more than available GPRs
It looks like the check is not needed with SB, because SB performs register allocation. What happens if you comment out the conditional which fails? Marek On Sun, Apr 20, 2014 at 1:30 AM, Marcello Maggioni wrote: > Hello, > > I realized while playing Diablo III on my machine that some shaders seem to > run out of available GPRs using r600g with my Macbook Pro with a HD6750m. > If the driver tries to do something to handle this case, but I couldn't find > any part inside the code that has to do with "spilling". > > There are some register related passes in SB, but none seems to be related > to possible spilling (anyway, the failing I get is in r600_shader.c:2148 > inside "r600_shader_from_tgsi()" which makes shader compiling failing > altogether skipping SB). > > How does r600g handle out of register situations? If it doesn't there are > plans to add this? > > Cheers, > Marcello > > ___ > 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] The way r600g handles shaders that use more than available GPRs
Hi Marek, I tried doing what you suggested and the game runs , but when the offending shader is loaded the game FPS drop to like 0.1 making everything unplayable. Other parts of the game (that don't make use of that shader, like menus and most of the levels) are fine though. With the check in place instead the performance is acceptable (I guess because the shader that fails to compile is not run altogether) Marcello 2014-04-20 2:02 GMT+01:00 Marek Olšák : > It looks like the check is not needed with SB, because SB performs > register allocation. What happens if you comment out the conditional > which fails? > > Marek > > On Sun, Apr 20, 2014 at 1:30 AM, Marcello Maggioni > wrote: > > Hello, > > > > I realized while playing Diablo III on my machine that some shaders seem > to > > run out of available GPRs using r600g with my Macbook Pro with a HD6750m. > > If the driver tries to do something to handle this case, but I couldn't > find > > any part inside the code that has to do with "spilling". > > > > There are some register related passes in SB, but none seems to be > related > > to possible spilling (anyway, the failing I get is in r600_shader.c:2148 > > inside "r600_shader_from_tgsi()" which makes shader compiling failing > > altogether skipping SB). > > > > How does r600g handle out of register situations? If it doesn't there are > > plans to add this? > > > > Cheers, > > Marcello > > > > ___ > > 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] fbo-generatemipmap-array regression after 5a2f8b2c48a14
Hi Brian, I bisected a nv50/nvc0 regression in fbo-generatemipmap-array to commit 5a2f8b2c48a14. The commit itself seems correct, but I double-checked my bisection results (at least on nv50, I only assume that it's the same commit causing the nvc0 regression). The nv50_set_sampler_views function also seems pretty simple and correct. Any ideas as to what to look at? Thanks, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] atan2 piglit failures since commit d877c643b
Hi Matt,
Starting with commit d877c643b ("glsl: Use M_PI_* macros."), I'm
seeing a few piglit failures on nvcf (GF116) for
generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-atan-vec2-vec2.shader_test
and its vs/gs counterparts. Curiously it works fine on nv50-family
chips. I checked the generated shaders, and the only differences are
the constants[1]. Does the generated test need to be adjusted to
expect more (or less) precise values perhaps? Or is it likely that
there's some bug in the shader that was being masked by the less
correct constants?
I haven't actually looked at the atan formula -- could it be that
those constants were "off" on purpose? Any other ideas?
Thanks,
-ilia
[1] : shader diff. scalar, intel-style syntax.
--- passing 2014-04-19 23:14:25.0 -0400
+++ failing 2014-04-19 23:01:10.0 -0400
@@ -21,7 +21,7 @@
00a0: bc00dde2 1af3f8c6 mov b32 $r3 0xbcfe31af
00a8: 94011de2 18f6c527 mov b32 $r4 0x3db149e5
00b0: 0c20dc00 3008 fma rn f32 $r3 $r2 $r3 $r4
-00b8: 54011de2 1af96f02 mov b32 $r4 0xbe5bc095
+00b8: 50011de2 1af96f02 mov b32 $r4 0xbe5bc094
00c0: 0c20dc00 3008 fma rn f32 $r3 $r2 $r3 $r4
00c8: 6c011de2 18ff243f mov b32 $r4 0x3fc90fdb
00d0: 0c209c00 3008 fma rn f32 $r2 $r2 $r3 $r4
@@ -32,15 +32,15 @@
00f8: 43f1dc00 220e4000 set $p0 0x1 gt f32 0x0 c0[0x10]
0100: 21f4 4000 join (not $p0) nop
0108: 03f1dc00 218e4000 set $p0 0x1 le f32 0x0 c0[0x0]
-0110: 7002 2901243f $p0 add f32 $r0 $r0 0x40490fdc
-0118: 70002002 2b01243f (not $p0) add f32 $r0 $r0 0xc0490fdc
+0110: 6c02 2901243f $p0 add f32 $r0 $r0 0x40490fdb
+0118: 6c002002 2b01243f (not $p0) add f32 $r0 $r0 0xc0490fdb
0120: 1df4 4000 join nop
0128: 1df4 4000 B join nop
0130: 1de4 28004000 B mov b32 $r0 c0[0x0]
0138: fc005c20 120e set f32 $r1 gt f32 $r0 0x0
0140: fc001c20 108e set f32 $r0 lt f32 $r0 0x0
0148: 00101d00 5000 add rn f32 $r0 $r1 neg $r0
-0150: 70001c12 30ff243f join mul f32 $r0 $r0 0x3fc90fdc
+0150: 6c001c12 30ff243f join mul f32 $r0 $r0 0x3fc90fdb
0158: 11205c44 10004000 B cvt f32 $r1 abs f32 c0[0x4]
0160: dc105c02 30c8af31 mul f32 $r1 $r1 0x322bcc77
0168: 0007 6005 joinat 0x2b0
@@ -64,7 +64,7 @@
01f8: bc011de2 1af3f8c6 mov b32 $r4 0xbcfe31af
0200: 94015de2 18f6c527 mov b32 $r5 0x3db149e5
0208: 10311c00 300a fma rn f32 $r4 $r3 $r4 $r5
-0210: 54015de2 1af96f02 mov b32 $r5 0xbe5bc095
+0210: 50015de2 1af96f02 mov b32 $r5 0xbe5bc094
0218: 10311c00 300a fma rn f32 $r4 $r3 $r4 $r5
0220: 6c015de2 18ff243f mov b32 $r5 0x3fc90fdb
0228: 1030dc00 300a fma rn f32 $r3 $r3 $r4 $r5
@@ -75,15 +75,15 @@
0250: 53f1dc00 220e4000 set $p0 0x1 gt f32 0x0 c0[0x14]
0258: 21f4 4000 join (not $p0) nop
0260: 13f1dc00 218e4000 set $p0 0x1 le f32 0x0 c0[0x4]
-0268: 70104002 2901243f $p0 add f32 $r1 $r1 0x40490fdc
-0270: 70106002 2b01243f (not $p0) add f32 $r1 $r1 0xc0490fdc
+0268: 6c104002 2901243f $p0 add f32 $r1 $r1 0x40490fdb
+0270: 6c106002 2b01243f (not $p0) add f32 $r1 $r1 0xc0490fdb
0278: 1df4 4000 join nop
0280: 1df4 4000 B join nop
0288: 10005de4 28004000 B mov b32 $r1 c0[0x4]
0290: fc109c20 120e set f32 $r2 gt f32 $r1 0x0
0298: fc105c20 108e set f32 $r1 lt f32 $r1 0x0
02a0: 04205d00 5000 add rn f32 $r1 $r2 neg $r1
-02a8: 70105c12 30ff243f join mul f32 $r1 $r1 0x3fc90fdc
+02a8: 6c105c12 30ff243f join mul f32 $r1 $r1 0x3fc90fdb
02b0: c0001d00 50004000 B add rn f32 $r0 $r0 neg c0[0x30]
02b8: d0105d00 50004000 add rn f32 $r1 $r1 neg c0[0x34]
02c0: 1c00 5800 mul rn f32 $r0 $r0 $r0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] atan2 piglit failures since commit d877c643b
On Sat, Apr 19, 2014 at 11:26 PM, Ilia Mirkin wrote:
> Hi Matt,
>
> Starting with commit d877c643b ("glsl: Use M_PI_* macros."), I'm
> seeing a few piglit failures on nvcf (GF116) for
>
> generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-atan-vec2-vec2.shader_test
>
> and its vs/gs counterparts. Curiously it works fine on nv50-family
Of note is that only vec2-vec2 and vec3-vec3 fail. float-float and
vec4-vec4 pass (as well as all the single-argument versions).
> chips. I checked the generated shaders, and the only differences are
> the constants[1]. Does the generated test need to be adjusted to
> expect more (or less) precise values perhaps? Or is it likely that
> there's some bug in the shader that was being masked by the less
> correct constants?
>
> I haven't actually looked at the atan formula -- could it be that
> those constants were "off" on purpose? Any other ideas?
>
> Thanks,
>
> -ilia
>
> [1] : shader diff. scalar, intel-style syntax.
> --- passing 2014-04-19 23:14:25.0 -0400
> +++ failing 2014-04-19 23:01:10.0 -0400
> @@ -21,7 +21,7 @@
> 00a0: bc00dde2 1af3f8c6 mov b32 $r3 0xbcfe31af
> 00a8: 94011de2 18f6c527 mov b32 $r4 0x3db149e5
> 00b0: 0c20dc00 3008 fma rn f32 $r3 $r2 $r3 $r4
> -00b8: 54011de2 1af96f02 mov b32 $r4 0xbe5bc095
> +00b8: 50011de2 1af96f02 mov b32 $r4 0xbe5bc094
> 00c0: 0c20dc00 3008 fma rn f32 $r3 $r2 $r3 $r4
> 00c8: 6c011de2 18ff243f mov b32 $r4 0x3fc90fdb
> 00d0: 0c209c00 3008 fma rn f32 $r2 $r2 $r3 $r4
> @@ -32,15 +32,15 @@
> 00f8: 43f1dc00 220e4000 set $p0 0x1 gt f32 0x0 c0[0x10]
> 0100: 21f4 4000 join (not $p0) nop
> 0108: 03f1dc00 218e4000 set $p0 0x1 le f32 0x0 c0[0x0]
> -0110: 7002 2901243f $p0 add f32 $r0 $r0 0x40490fdc
> -0118: 70002002 2b01243f (not $p0) add f32 $r0 $r0 0xc0490fdc
> +0110: 6c02 2901243f $p0 add f32 $r0 $r0 0x40490fdb
> +0118: 6c002002 2b01243f (not $p0) add f32 $r0 $r0 0xc0490fdb
> 0120: 1df4 4000 join nop
> 0128: 1df4 4000 B join nop
> 0130: 1de4 28004000 B mov b32 $r0 c0[0x0]
> 0138: fc005c20 120e set f32 $r1 gt f32 $r0 0x0
> 0140: fc001c20 108e set f32 $r0 lt f32 $r0 0x0
> 0148: 00101d00 5000 add rn f32 $r0 $r1 neg $r0
> -0150: 70001c12 30ff243f join mul f32 $r0 $r0 0x3fc90fdc
> +0150: 6c001c12 30ff243f join mul f32 $r0 $r0 0x3fc90fdb
> 0158: 11205c44 10004000 B cvt f32 $r1 abs f32 c0[0x4]
> 0160: dc105c02 30c8af31 mul f32 $r1 $r1 0x322bcc77
> 0168: 0007 6005 joinat 0x2b0
> @@ -64,7 +64,7 @@
> 01f8: bc011de2 1af3f8c6 mov b32 $r4 0xbcfe31af
> 0200: 94015de2 18f6c527 mov b32 $r5 0x3db149e5
> 0208: 10311c00 300a fma rn f32 $r4 $r3 $r4 $r5
> -0210: 54015de2 1af96f02 mov b32 $r5 0xbe5bc095
> +0210: 50015de2 1af96f02 mov b32 $r5 0xbe5bc094
> 0218: 10311c00 300a fma rn f32 $r4 $r3 $r4 $r5
> 0220: 6c015de2 18ff243f mov b32 $r5 0x3fc90fdb
> 0228: 1030dc00 300a fma rn f32 $r3 $r3 $r4 $r5
> @@ -75,15 +75,15 @@
> 0250: 53f1dc00 220e4000 set $p0 0x1 gt f32 0x0 c0[0x14]
> 0258: 21f4 4000 join (not $p0) nop
> 0260: 13f1dc00 218e4000 set $p0 0x1 le f32 0x0 c0[0x4]
> -0268: 70104002 2901243f $p0 add f32 $r1 $r1 0x40490fdc
> -0270: 70106002 2b01243f (not $p0) add f32 $r1 $r1 0xc0490fdc
> +0268: 6c104002 2901243f $p0 add f32 $r1 $r1 0x40490fdb
> +0270: 6c106002 2b01243f (not $p0) add f32 $r1 $r1 0xc0490fdb
> 0278: 1df4 4000 join nop
> 0280: 1df4 4000 B join nop
> 0288: 10005de4 28004000 B mov b32 $r1 c0[0x4]
> 0290: fc109c20 120e set f32 $r2 gt f32 $r1 0x0
> 0298: fc105c20 108e set f32 $r1 lt f32 $r1 0x0
> 02a0: 04205d00 5000 add rn f32 $r1 $r2 neg $r1
> -02a8: 70105c12 30ff243f join mul f32 $r1 $r1 0x3fc90fdc
> +02a8: 6c105c12 30ff243f join mul f32 $r1 $r1 0x3fc90fdb
> 02b0: c0001d00 50004000 B add rn f32 $r0 $r0 neg c0[0x30]
> 02b8: d0105d00 50004000 add rn f32 $r1 $r1 neg c0[0x34]
> 02c0: 1c00 5800 mul rn f32 $r0 $r0 $r0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] atan2 piglit failures since commit d877c643b
On Sat, Apr 19, 2014 at 8:26 PM, Ilia Mirkin wrote:
> Hi Matt,
>
> Starting with commit d877c643b ("glsl: Use M_PI_* macros."), I'm
> seeing a few piglit failures on nvcf (GF116) for
>
> generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-atan-vec2-vec2.shader_test
Strange. They all pass for me on Haswell before and after the change.
> and its vs/gs counterparts. Curiously it works fine on nv50-family
> chips. I checked the generated shaders, and the only differences are
> the constants[1]. Does the generated test need to be adjusted to
> expect more (or less) precise values perhaps? Or is it likely that
> there's some bug in the shader that was being masked by the less
> correct constants?
>
> I haven't actually looked at the atan formula -- could it be that
> those constants were "off" on purpose? Any other ideas?
No, Paul's commit message for d4c80f5f confirms the constants.
That only some of combinations fail for you makes me think it's
something driver specific that this patch unwittingly uncovered.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] atan2 piglit failures since commit d877c643b
On Sun, Apr 20, 2014 at 12:50 AM, Matt Turner wrote:
> On Sat, Apr 19, 2014 at 8:26 PM, Ilia Mirkin wrote:
>> Hi Matt,
>>
>> Starting with commit d877c643b ("glsl: Use M_PI_* macros."), I'm
>> seeing a few piglit failures on nvcf (GF116) for
>>
>> generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-atan-vec2-vec2.shader_test
>
> Strange. They all pass for me on Haswell before and after the change.
>
>> and its vs/gs counterparts. Curiously it works fine on nv50-family
>> chips. I checked the generated shaders, and the only differences are
>> the constants[1]. Does the generated test need to be adjusted to
>> expect more (or less) precise values perhaps? Or is it likely that
>> there's some bug in the shader that was being masked by the less
>> correct constants?
>>
>> I haven't actually looked at the atan formula -- could it be that
>> those constants were "off" on purpose? Any other ideas?
>
> No, Paul's commit message for d4c80f5f confirms the constants.
>
> That only some of combinations fail for you makes me think it's
> something driver specific that this patch unwittingly uncovered.
Hm, something odd that I noticed in the generated test:
uniform vec2 arg0 1e+10 1e+10
uniform vec2 arg1 0.0 1e-10
uniform vec2 expected 1.5707964 1.5707964
uniform float tolerance 0.0022214416
draw rect -1 -1 2 2
However
>>> math.atan2(1e10, 0)
1.5707963267948966
>>> math.atan2(1e10, 1e-10)
1.5707963267948966
Has the same very wrong rounding issue that your commit fixed. I'm
still trying to work out how generated_tests/builtin_function.py
works, but I suspect it's related. And it's unclear to me whether the
tolerance takes the dimensionality into account (since it's a
tolerance on the distance between expected and result, it needs to be
scaled). But like I said, I'm still very confused by that generator
code, perhaps it does all that correctly.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
