[Mesa-dev] [Bug 36083] Feature wish: EXT_gpu_shader4
https://bugs.freedesktop.org/show_bug.cgi?id=36083 --- Comment #1 from s3734...@mail.zih.tu-dresden.de 2011-04-16 00:26:01 PDT --- Created an attachment (id=45694) View: https://bugs.freedesktop.org/attachment.cgi?id=45694 Review: https://bugs.freedesktop.org/review?bug=36083&attachment=45694 First start This patch does a first step towards implementing gpu_shader4: gl_InstanceID Even if it's a small change, please review the patch. It also fixes a issue with Unigine Heaven. -- 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 36083] Feature wish: EXT_gpu_shader4
https://bugs.freedesktop.org/show_bug.cgi?id=36083 --- Comment #2 from Marek Olšák 2011-04-16 00:59:00 PDT --- If you are fixing a driver by this, let's just disable the extension until gl_InstanceID is supported. I can disable it for r600g if you like. -- 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 36083] Feature wish: EXT_gpu_shader4
https://bugs.freedesktop.org/show_bug.cgi?id=36083 --- Comment #3 from s3734...@mail.zih.tu-dresden.de 2011-04-16 01:14:32 PDT --- i'm not fixing a driver, Unigine Heaven uses EXT_gpu_shader4 without checking for it. So disabling an extension would not solve the problem. I'm serious. This is the start of implementing EXT_gpu_shader4 in mesa. -- 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 36083] Feature wish: EXT_gpu_shader4
https://bugs.freedesktop.org/show_bug.cgi?id=36083 --- Comment #4 from Marek Olšák 2011-04-16 01:24:51 PDT --- No, Heaven doesn't use EXT_gpu_shader4. Or maybe it does, but it doesn't require it if the extension is not exposed by a driver. Heaven is only incorrectly using GL_ARB_draw_instanced. Note that Heaven works on r300g and r600g has a very similar extension list, so it should work too. -- 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 36083] Feature wish: EXT_gpu_shader4
https://bugs.freedesktop.org/show_bug.cgi?id=36083 --- Comment #5 from s3734...@mail.zih.tu-dresden.de 2011-04-16 01:29:36 PDT --- But that's not Topic of this bug report. Should I open an other one to fix the Unigine Heaven problem? This bug report should stay for gpu_shader4 issues -- 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] per-vertex array max_index
Indeed, we need to compute per-element max_index (per buffer doesn't quite work because the same buffer can be referred by different element with different strides and offsets), and clamp separately against them. A different name for the "hard" max_index sounds good, but I'm not sure what's good. What about "clamp_index"? I'm also not sure what's the best place to do this -- state tracker or pipe driver. At any rate, let's fix u_draw.c code to return per-element clamp_indices, fix draw module, and then decide. Jose - Original Message - From: "Brian Paul" To: "José Fonseca" Cc: "mesa-dev" Sent: Saturday, April 16, 2011 1:29:34 AM Subject: Re: [Mesa-dev] per-vertex array max_index On 04/15/2011 02:17 PM, José Fonseca wrote: > On 04/15/2011 09:14 PM, José Fonseca wrote: >> On 04/15/2011 08:51 PM, Brian Paul wrote: >>> On 04/15/2011 01:41 PM, José Fonseca wrote: >>> On 04/15/2011 07:20 PM, Christoph Bumiller wrote: > On 15.04.2011 18:04, Brian Paul wrote: > > >> Hi Marek, >> >> Back on Jan 10 you removed the per-vertex array max_index field >> (commit cdca3c58aa2d9549f5188910e2a77b438516714f). I believe this was >> a mistake. >> >> I noticed today that the piglit draw-instanced-divisor test is >> failing. A bisection points to Jose's commit >> 17bbc1f0425b3768e26473eccea5f2570dcb26d3. But that's a red herring. >> If I disable the SSE code paths, the regression goes back to the Jan >> 10 change. >> >> With the GL_ARB_instanced_arrays extension vertex array indexing >> changes quite a bit. Specifically, some arrays (those with divisors >> != 0) are now indexed by instance ID, not the primitive's vertex >> index. The draw_info::max_index field doesn't let us take this into >> account. I believe that we really need a per-array max_index value. >> >> As an example, suppose we're drawing a star field with 1 million >> instanced stars, each star drawn as a 4-vertex quad. We might use a >> vertex array indexed by the instance ID to color the stars. >> >> The draw call would look like: >> >> glDrawArraysInstanced(GL_QUADS, 0, 4, 1000*1000); >> >> In this case we'd have two vertex arrays. The first array is the quad >> vertex positions with four elements. The second array is the star >> colors with 1 million elements. As it is now, we're setting >> draw_info::max_index = 4 and we errantly clamp the index into the >> second array to 4 instead of 1 million. >> >> As a temporary work around we can disable clamping of array indexes >> for instance arrays. But I think we need to revert the Jan 10 commit >> and then rework some of Jose's related changes. >> >> -Brian >> >> >> > You know which vertex elements are per-instance, you know the divisor, > and you know the max instance index - that should be all the information > you need. > > You just have to clamp it to startInstance + instanceCount for them > instead. Yes, but I'm interested in clamping it to the VBO bounds so we don't read random data. draw_info::max_index is an optimization hint. In theory it could be always 0xfff and the pipe driver should still cope with it. Provided it is an upper bound of the true max index in the index buffer it should cause no visible difference. My u_draw.c code already ignores instanced elements when computing max_index. And I believe the translate module doesn't clamp to max_index when fetching instanced elements, but I'll have to double check. It does clamp, both in the generic and SSE code. That's the cause of the draw-instanced-divisor failure. I didn't look too closely at current st_draw.c code though yet. But it appears the bug is in st_draw.c, as there is no need to artificially limit the max_index passed by the app. >>> I thought we were using max_index to prevent out-of-bounds buffer >>> reads. Are we not doing that anywhere? >>> >>> >> >> Inside the draw module there is a max_index with that meaning that: >> draw_context->pt.max_index. Note that we're not passing that to the translate->set_buffer() calls. We're actually passing draw->pt.user.max_index. Is that a bug? I think having two different max_index variables/fields with slightly different meanings is a problem. I'd suggest renaming one or the other to make the meaning more obvious. >> This is all very subtle, but min_index/max_index is really a property >> of the index_buffer alone, independent of vertex buffers size and/or >> any index_bias. >> >> src/gallium/docs/source/context.rst could be a bit better... This is >> what it has currently: >> >> All vertex indices must fall inside the range given by >> ``min_index`` and >> ``max_index``. In case non-indexed draw, ``min_index`` should be >> set to >> ``start`
[Mesa-dev] [Bug 36295] Incorrect rendering in SPECviewperf benchmark
https://bugs.freedesktop.org/show_bug.cgi?id=36295 José Fonseca changed: What|Removed |Added Product|DRI |Mesa Version|unspecified |git Component|DRM/Radeon |Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org CC||bri...@vmware.com --- Comment #2 from José Fonseca 2011-04-16 02:50:43 PDT --- This is a bug in SPECviewperf11, which relies on NV_fragment_program2 extension, even when it is not advertised. Me and Brian have a patch that workarounds this by tolerating NV_fragment_program2 's IF/ELSE/ENDIF opcodes. This is exactly the same stratergy that AMD's fglrx drivers took: not advertise NVIDIA's extension, but silently handle it. -- 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] per-vertex array max_index
On 16.04.2011 02:29, Brian Paul wrote: > On 04/15/2011 03:33 PM, Marek Olšák wrote: >> Let's decompose the whole problem of computing max_index into several >> cases: >> >> 1) Is the vertex buffer a non-user buffer? >> - If stride == 0, max_index = 1. >> - Otherwise, max_index = (width0 - buffer_offset - src_offset) / >> stride - 1. >> >> That should work for user vertex buffers too, but there is an >> alternative way without having to use width0, it's what st/mesa is doing >> (though it might be wrong for instanced arrays, I didn't check): >> >> 2) Is the vertex buffer a user buffer? >> - If stride == 0, max_index = 1. >> - If instance_divisor != 0, max_index = start_instance + >> instance_count - 1. >> - If !indexed, max_index = start + count - 1. >> - Otherwise, st/mesa must go through the index buffer and obtain >> max_index from there (which it does). >> >> There is no other way to compute max_index from the info we have from >> GL. > > Right, I understand all that. > > >> So that's all for the max_index issue. > > But according to Jose, draw_info::max_index has nothing to do with > bounds checking; it basically describes the range of indexes specified > by the user in glDrawElements(). The driver can use this as a hint to > minimize fetching/moving/copying vertex data. > But you can't do bounds checking on user (non-VBO) vertex buffers anyway, you have to rely on the user to not specify out-of-bounds indices. For VBOs you still have the buffer size / stride as a bound against which you can check draw info's max_index (from index buffer or array start + count, either way that's per draw call) or max_instance. If the state tracker sets max_index to ~0 (like d3d1x always does), it obviously didn't care to compute the max index for you and you're left with checking against the provided buffer size (which luckily the GPU does for me, I agree bounds checking is quite useful). Wouldn't vertex_buffer.max_index just be something like MIN(draw_info.max_index, buffer_size / element_size) ? > It seems there's a disconnect here between what you describe above and > what Jose described for draw_info::max_index. > > Note that draw_info::max_index is passed all the way down into the > gallium vertex translation module where it's applied to all vertex > array indexing, including instanced arrays. And that's causing the > current failures. > Would it be a problem to just not apply it to per-instance buffers / elements ? > >> On a slightly different note, we can't completely decouple the >> set_vertex_buffer and draw_vbo calls due to some trickery in the vbo >> module, so there is still a long way to go to make the two really >> independent of each other, i.e. several glDrawElements calls shouldn't >> cause calling set_vertex_buffer each time, but they sometimes do. > > It seems to me that at least in some cases, we could bypass the VBO > module completely when drawing from VBOs and vertex arrays. I haven't > explored that in any detail though. > > Another idea I had was to take more advantage of Vertex Array Objects. > With VAOs, all the info about the arrays is packaged up into a nice > data structure (gl_array_object) that the state tracker could augment > with gallium vertex array info. If we do a sequence of glDraw() calls > with one VAO, we should be able to reuse the gallium vertex array info > associated with the VAO and not recompute all that stuff. > > -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] [PATCH] r200: enable EXT_gpu_program_parameters
Signed-off-by: Nicolas Kaiser
---
According to Marek Olšák, this extension is quite popular in
the GL community.[1]
Tests look good:
./src/tests/prog_parameter
GL_RENDERER = Mesa DRI R200 (R200 514D) TCL DRI2
GL_VERSION = 1.3 Mesa 7.11-devel (git-4ee40c3)
GL_EXT_gpu_program_parameters available, testing that path.
Testing glProgramEnvParameter4fvARB (count = 256)...
Testing glProgramEnvParameters4fvEXT (count = 256)...
Testing glProgramLocalParameter4fvARB (count = 1024)...
Testing glProgramLocalParameters4fvEXT (count = 1024)...
PASS!
Best regards,
Nicolas Kaiser
[1] http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12980.html
src/mesa/drivers/dri/r200/r200_context.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_context.c
b/src/mesa/drivers/dri/r200/r200_context.c
index 4773263..d19370e 100644
--- a/src/mesa/drivers/dri/r200/r200_context.c
+++ b/src/mesa/drivers/dri/r200/r200_context.c
@@ -69,6 +69,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
#define need_GL_EXT_secondary_color
#define need_GL_EXT_blend_equation_separate
#define need_GL_EXT_blend_func_separate
+#define need_GL_EXT_gpu_program_parameters
#define need_GL_NV_vertex_program
#define need_GL_ARB_point_parameters
#define need_GL_EXT_framebuffer_object
@@ -123,6 +124,7 @@ static const struct dri_extension card_extensions[] =
{ "GL_EXT_blend_minmax", GL_EXT_blend_minmax_functions },
{ "GL_EXT_blend_subtract", NULL },
{ "GL_EXT_fog_coord", GL_EXT_fog_coord_functions },
+{ "GL_EXT_gpu_program_parameters",
GL_EXT_gpu_program_parameters_functions},
{ "GL_EXT_packed_depth_stencil", NULL},
{ "GL_EXT_secondary_color",GL_EXT_secondary_color_functions },
{ "GL_EXT_stencil_wrap", NULL },
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 35814] [TRACKER] ARB_texture_float extension support
https://bugs.freedesktop.org/show_bug.cgi?id=35814 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Olšák 2011-04-16 03:41:30 PDT --- The core support of ARB_texture_float has been pushed to master. Closing. -- 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] [PATCH] st/mesa: expose ARB_draw_instanced only if EXT_gpu_shader4 is available too
>From GL_ARB_draw_instanced:
EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required.
which means we can't advertise it. :( Well at least apps won't be looking
for gl_InstanceID.
---
src/mesa/state_tracker/st_extensions.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index bdc0894..3460fe0 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -560,7 +560,8 @@ void st_init_extensions(struct st_context *st)
ctx->Extensions.ARB_shader_stencil_export = GL_TRUE;
}
- if (screen->get_param(screen, PIPE_CAP_TGSI_INSTANCEID)) {
+ if (ctx->Extensions.EXT_gpu_shader4 &&
+ screen->get_param(screen, PIPE_CAP_TGSI_INSTANCEID)) {
ctx->Extensions.ARB_draw_instanced = GL_TRUE;
}
if (screen->get_param(screen, PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR)) {
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36299] New: Patch: more verbose error log while loading compressed Textures
https://bugs.freedesktop.org/show_bug.cgi?id=36299 Summary: Patch: more verbose error log while loading compressed Textures Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: s3734...@mail.zih.tu-dresden.de Created an attachment (id=45707) --> (https://bugs.freedesktop.org/attachment.cgi?id=45707) Print a reason why compressed_texture_error_check fails Hi, Unigine heaven fails to load compressed textures, but the only output was "Mesa: User error: GL_INVALID_ENUM in glTexImage2D" So I decided to change the error checking routine a bit to see where the actual problems are. This is the patch. Commit message: "Print a reason why compressed_texture_error_check fails" -- 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] Patch: more verbose error log while loading compressed Textures
Hi, Unigine heaven fails to load compressed textures, but the only output was "Mesa: User error: GL_INVALID_ENUM in glTexImage2D" So I decided to change the error checking routine a bit to see where the actual problems are. This is the patch. Commit message: "Print a reason why compressed_texture_error_check fails" ZGlmZiAtLWdpdCBhL3NyYy9tZXNhL21haW4vdGV4aW1hZ2UuYyBiL3NyYy9tZXNhL21haW4vdGV4 aW1hZ2UuYwppbmRleCBjNWM0NTQzLi5jNWYyN2U1IDEwMDY0NAotLS0gYS9zcmMvbWVzYS9tYWlu L3RleGltYWdlLmMKKysrIGIvc3JjL21lc2EvbWFpbi90ZXhpbWFnZS5jCkBAIC0zMDQwLDM2ICsz MDQwLDQ4IEBAIGNvbXByZXNzZWRfdGV4dHVyZV9lcnJvcl9jaGVjayhzdHJ1Y3QgZ2xfY29udGV4 dCAqY3R4LCBHTGludCBkaW1lbnNpb25zLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEdMZW51bSB0YXJnZXQsIEdMaW50IGxldmVsLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEdMZW51bSBpbnRlcm5hbEZvcm1hdCwgR0xzaXplaSB3aWR0aCwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBHTHNpemVpIGhlaWdodCwgR0xzaXplaSBkZXB0aCwgR0xpbnQgYm9y ZGVyLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdMc2l6ZWkgaW1hZ2VTaXplKQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdMc2l6ZWkgaW1hZ2VTaXplLCBjaGFyKiog cmVhc29uKQogewogICAgY29uc3QgR0xlbnVtIHByb3h5VGFyZ2V0ID0gZ2V0X3Byb3h5X3Rhcmdl dCh0YXJnZXQpOwogICAgY29uc3QgR0xpbnQgbWF4TGV2ZWxzID0gX21lc2FfbWF4X3RleHR1cmVf bGV2ZWxzKGN0eCwgdGFyZ2V0KTsKICAgIEdMaW50IGV4cGVjdGVkU2l6ZTsKKyAgICpyZWFzb24g PSAidW5rbm93biI7CiAKICAgIC8qIGNoZWNrIGxldmVsICovCi0gICBpZiAobGV2ZWwgPCAwIHx8 IGxldmVsID49IG1heExldmVscykKKyAgIGlmIChsZXZlbCA8IDAgfHwgbGV2ZWwgPj0gbWF4TGV2 ZWxzKSB7CisJICAgKnJlYXNvbiA9ICJsZXZlbCI7CiAgICAgICByZXR1cm4gR0xfSU5WQUxJRF9W QUxVRTsKKyAgIH0KIAogICAgaWYgKCF0YXJnZXRfY2FuX2JlX2NvbXByZXNzZWQoY3R4LCB0YXJn ZXQsIGludGVybmFsRm9ybWF0KSkgeworCQkqcmVhc29uID0gInRhcmdldCI7CiAgICAgICByZXR1 cm4gR0xfSU5WQUxJRF9FTlVNOwogICAgfQogCiAgICAvKiBUaGlzIHdpbGwgZGV0ZWN0IGFueSBp bnZhbGlkIGludGVybmFsRm9ybWF0IHZhbHVlICovCi0gICBpZiAoIV9tZXNhX2lzX2NvbXByZXNz ZWRfZm9ybWF0KGN0eCwgaW50ZXJuYWxGb3JtYXQpKQorICAgaWYgKCFfbWVzYV9pc19jb21wcmVz c2VkX2Zvcm1hdChjdHgsIGludGVybmFsRm9ybWF0KSkgeworCQkqcmVhc29uID0gImludGVybmFs Rm9ybWF0IjsKICAgICAgIHJldHVybiBHTF9JTlZBTElEX0VOVU07CisJfQogCiAgICAvKiBUaGlz IHNob3VsZCByZWFsbHkgbmV2ZXIgZmFpbCAqLwotICAgaWYgKF9tZXNhX2Jhc2VfdGV4X2Zvcm1h dChjdHgsIGludGVybmFsRm9ybWF0KSA8IDApCisgICBpZiAoX21lc2FfYmFzZV90ZXhfZm9ybWF0 KGN0eCwgaW50ZXJuYWxGb3JtYXQpIDwgMCkgeworCQkqcmVhc29uID0gInRoaXMgc2hvdWxkIG5l dmVyIGZhaWwiOwogICAgICAgcmV0dXJuIEdMX0lOVkFMSURfRU5VTTsKKwl9CiAKICAgIC8qIE5v IGNvbXByZXNzZWQgZm9ybWF0cyBzdXBwb3J0IGJvcmRlcnMgYXQgdGhpcyB0aW1lICovCi0gICBp ZiAoYm9yZGVyICE9IDApCisgICBpZiAoYm9yZGVyICE9IDApIHsKKwkJKnJlYXNvbiA9ICJib3Jk ZXJzIG5vdCBhbG93ZWQgaW4gY29tcHJlc3NlZCBmb3JtYXRzIjsKICAgICAgIHJldHVybiBHTF9J TlZBTElEX1ZBTFVFOworCX0KIAogICAgLyogRm9yIGN1YmUgbWFwLCB3aWR0aCBtdXN0IGVxdWFs IGhlaWdodCAqLwogICAgaWYgKHRhcmdldCA+PSBHTF9URVhUVVJFX0NVQkVfTUFQX1BPU0lUSVZF X1hfQVJCICYmCi0gICAgICAgdGFyZ2V0IDw9IEdMX1RFWFRVUkVfQ1VCRV9NQVBfTkVHQVRJVkVf Wl9BUkIgJiYgd2lkdGggIT0gaGVpZ2h0KQorICAgICAgIHRhcmdldCA8PSBHTF9URVhUVVJFX0NV QkVfTUFQX05FR0FUSVZFX1pfQVJCICYmIHdpZHRoICE9IGhlaWdodCkgeworICAgICAgKnJlYXNv biA9ICJ3aWR0aCBtdXN0IGJlIGVxdWFsIGhlaWdodCI7CiAgICAgICByZXR1cm4gR0xfSU5WQUxJ RF9WQUxVRTsKKwl9CiAKICAgIC8qIGNoZWNrIGltYWdlIHNpemUgYWdhaW5zdCBjb21wcmVzc2lv biBibG9jayBzaXplICovCiAgICB7CkBAIC0zMDg2LDYgKzMwOTgsNyBAQCBjb21wcmVzc2VkX3Rl eHR1cmVfZXJyb3JfY2hlY2soc3RydWN0IGdsX2NvbnRleHQgKmN0eCwgR0xpbnQgZGltZW5zaW9u cywKICAgICAgICAgICAqIGdlbmVyYXRlZCBbLi4uXSBpZiBhbnkgcGFyYW1ldGVyIGNvbWJpbmF0 aW9ucyBhcmUgbm90CiAgICAgICAgICAgKiBzdXBwb3J0ZWQgYnkgdGhlIHNwZWNpZmljIGNvbXBy ZXNzZWQgaW50ZXJuYWwgZm9ybWF0LiAKICAgICAgICAgICAqLworICAgICAgICAgKnJlYXNvbiA9 ICJwYXJhbWV0ZXIgY29tYmluYXRpb24gbm90IHN1cHBvcnRlZCI7CiAgICAgICAgICByZXR1cm4g R0xfSU5WQUxJRF9PUEVSQVRJT047CiAgICAgICB9CiAgICB9CkBAIC0zMDk1LDYgKzMxMDgsNyBA QCBjb21wcmVzc2VkX3RleHR1cmVfZXJyb3JfY2hlY2soc3RydWN0IGdsX2NvbnRleHQgKmN0eCwg R0xpbnQgZGltZW5zaW9ucywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aW50ZXJuYWxGb3JtYXQsIEdMX05PTkUsIEdMX05PTkUsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHdpZHRoLCBoZWlnaHQsIGRlcHRoLCBib3JkZXIpKSB7CiAgICAgICAv KiBTZWUgZXJyb3IgY29tbWVudCBhYm92ZSAqLworICAgICAgKnJlYXNvbiA9ICJjaGVja2luZyBp bWFnZSBzaXplIGZhaWxlZCI7CiAgICAgICByZXR1cm4gR0xfSU5WQUxJRF9PUEVSQVRJT047CiAg ICB9CiAKQEAgLTMxMDUsNiArMzExOSw4IEBAIGNvbXByZXNzZWRfdGV4dHVyZV9lcnJvcl9jaGVj ayhzdHJ1Y3QgZ2xfY29udGV4dCAqY3R4LCBHTGludCBkaW1lbnNpb25zLAogICAgICAgICogaWYg PGltYWdlU2l6ZT4gaXMgbm90IGNvbnNpc3RlbnQgd2l0aCB0aGUgZm9ybWF0LCBkaW1lbnNpb25z LCBhbmQKICAgICAgICAqIGNvbnRlbnRzIG9mIHRoZSBzcGVjaWZpZWQgaW1hZ2UuCiAgICAgICAg Ki8KKyAgICAgICpyZWFzb24gPSAiaW1hZ2VTaXplIGlzIG5vdCBjb25zaXN0ZW50IHdpdGggdGhl IGZvcm1hdCwiXAorICAgICAgICAgICAgICJkaW1lbnNpb25zIGFuZCBjb250ZW50cyBvZiB0aGUg c3BlY2lmaWVkIGltYWdlIjsKICAgICAgIHJldHVybiBHTF9JTlZBTElEX1ZBTFVFOwogICAgfQog CkBAIC0zMjc3LDE0ICszMjkzLDE1IEBAIGNvbXByZXNzZWR0ZXhpbWFnZShzdHJ1Y3QgZ2xfY29u dGV4dCAqY3R4LCBHTHVpbnQgZGltcywKICAgICAgIHJldHVybjsKICAgIH0KIAorICAgY2hhciAq cmVhc29uOwogICAgZXJyb3IgPSBjb21wcmVzc2VkX3RleHR1cmVfZXJyb3JfY2hlY2soY3R4LCBk aW1zLCB0YXJnZXQsIGxldmVsLAogICAgICAgICAgICAgICAgICAgIC
Re: [Mesa-dev] [PATCH 2/9] mesa: gl_fragment_program::FogOption is always GL_NONE so don't check it
On Sat, Apr 16, 2011 at 12:10 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> ---
> src/mesa/swrast/s_context.c | 15 ---
> src/mesa/tnl/t_context.c | 12
> 2 files changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
> index 491fcfc..b3e3968 100644
> --- a/src/mesa/swrast/s_context.c
> +++ b/src/mesa/swrast/s_context.c
> @@ -248,18 +248,11 @@ _swrast_update_fog_state( struct gl_context *ctx )
> SWcontext *swrast = SWRAST_CONTEXT(ctx);
> const struct gl_fragment_program *fp = ctx->FragmentProgram._Current;
>
> + assert((fp == NULL) || (fp->Base.Target == GL_FRAGMENT_PROGRAM_ARB));
> +
> /* determine if fog is needed, and if so, which fog mode */
> - swrast->_FogEnabled = GL_FALSE;
> - if (fp && fp->Base.Target == GL_FRAGMENT_PROGRAM_ARB) {
> - if (fp->FogOption != GL_NONE) {
> - swrast->_FogEnabled = GL_TRUE;
> - swrast->_FogMode = fp->FogOption;
> - }
> - }
> - else if (ctx->Fog.Enabled) {
> - swrast->_FogEnabled = GL_TRUE;
> - swrast->_FogMode = ctx->Fog.Mode;
> - }
> + swrast->_FogEnabled = (fp == NULL && ctx->Fog.Enabled);
> + swrast->_FogMode = ctx->Fog.Mode;
We might as well get rid of swrast->_FogMode and just use
ctx->Fog.Mode everywhere.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 23884] Unigine Tropics demo requires float textures
https://bugs.freedesktop.org/show_bug.cgi?id=23884 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Sven Arvidsson 2011-04-16 06:56:19 PDT --- I guess this can be closed now :] -- 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 36299] Patch: more verbose error log while loading compressed Textures
https://bugs.freedesktop.org/show_bug.cgi?id=36299 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul 2011-04-16 07:15:09 PDT --- Thanks. I've cleaned up the patch a bit and will commit it soon. -- 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: expose ARB_draw_instanced only if EXT_gpu_shader4 is available too
On Sat, Apr 16, 2011 at 5:06 AM, Marek Olšák wrote: > From GL_ARB_draw_instanced: > > EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required. > > which means we can't advertise it. :( Well at least apps won't be looking > for gl_InstanceID. I believe that the GL_ARB_draw_instanced spec is wrong about that. There's really no reason why instancing depends on those extensions. I think that Ian has reported this issue along with gl_InstanceID vs. gl_InstanceIDARB to the ARB so the spec may be changed soon. Typically, ARB extensions do not directly depend on EXT extensions. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36282] glxgears segfault with swrast
https://bugs.freedesktop.org/show_bug.cgi?id=36282 --- Comment #2 from Alexandre Demers 2011-04-16 07:45:45 PDT --- I'll help you on that one. I also have the same problem here on r600g. At first, I thought it was something with Natty (I just upgraded to beta 2). But it's very similar. I also have tested with swrast and it also crashed. I'll be bisecting on my side and see if I find the same thing as you. -- 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 36282] glxgears segfault with swrast
https://bugs.freedesktop.org/show_bug.cgi?id=36282 --- Comment #3 from Alexandre Demers 2011-04-16 09:43:26 PDT --- Bisecting gave me the following: 34a5d3b9f4740601708c82093e2114356d749e65 is the first bad commit commit 34a5d3b9f4740601708c82093e2114356d749e65 Author: Brian Paul Date: Sun Apr 10 12:48:28 2011 -0600 mesa: plug in new functions for GL_ARB_sampler_objects Build the new sources, plug the new functions into the dispatch table, implement display list support. And enable extension in the gallium state tracker. :04 04 50d8747e0dc22e1634407703563447bd0e1c44d3 be44081fa9ea33563f8582df370cfb13a0d5c256 M src -- 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 36282] glxgears segfault with swrast
https://bugs.freedesktop.org/show_bug.cgi?id=36282 Alexandre Demers changed: What|Removed |Added CC||alexandre.f.dem...@gmail.co ||m -- 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 0/9] Big pile of fog clean up
On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick wrote: > This patch series cleans out the last vestiges of fixed-function fog > support with ARB_fragment_program. We talked about doing this quite > some time ago, but we decided to hold off. The thinking at the time > was that there was still a chance that someone might add support for > the fixed-function fog on either i915 or r300. > > Reality check: there is no chance because nobody cares. :) > > Patch 1/9 cleans up a couple minor bugs in the fixed-function > fragment program code. > > Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to > be non-GL_NONE. Thanks to the first patch, this can *never* happen. > > Patch 5/9 removes gl_fragment_program::FogOption. > > The remaining four patches remove all the dangling bits of support for > fixed-function fog on i915. Since fog is (and always has been) > handled by fragment programs on i915, this code is completely useless. > > I have tested this whole series on Ironlake (i965 driver) and G33 > (i915 driver). There were no piglit or GTF regressions in either > case. > > I believe that, at the very least, the first four patches are suitable > for the stable branches (after a suitable settling period on master, > of course). The remaining five patches may also be suitable. > > src/mesa/drivers/dri/i915/i915_context.c | 8 +- > src/mesa/drivers/dri/i915/i915_context.h | 15 -- > src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +-- > src/mesa/drivers/dri/i915/i915_state.c | 164 > +--- > src/mesa/drivers/dri/i915/i915_vtbl.c | 9 - > src/mesa/drivers/dri/i965/brw_program.c | 5 - > .../drivers/dri/r300/compiler/r300_fragprog_emit.c | 2 - > src/mesa/main/ff_fragment_shader.cpp | 44 +++--- > src/mesa/main/mtypes.h | 1 - > src/mesa/program/arbprogparse.c | 18 +-- > src/mesa/program/program.c | 1 - > src/mesa/program/programopt.c | 33 +++-- > src/mesa/program/programopt.h | 4 +- > src/mesa/swrast/s_context.c | 15 +-- > src/mesa/tnl/t_context.c | 12 +- > 15 files changed, 70 insertions(+), 272 deletions(-) r300 *did* support FF fog at one point, but it got tossed out because we couldn't get it to work with fog coordinates. (Well, *I* couldn't get it to work; I think osiris got it mostly-working-sort-of at one point.) This code will not be missed. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36282] glxgears segfault with swrast
https://bugs.freedesktop.org/show_bug.cgi?id=36282 Alexandre Demers changed: What|Removed |Added Platform|x86 (IA32) |All -- 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] [PATCH] st/mesa: fix WPOS adjustment
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.
>From f150c14f8d33f5898b47d5ef01aef5aa051aa841 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Sat, 16 Apr 2011 18:38:16 +0200
Subject: [PATCH] st/mesa: fix WPOS adjustment
For the first change, where we want to convert from half integer
to integer coordinates, consider the upper left position:
u,h -> l,i / 0.5 -> 99.0 : ( 0.5 - 0.5) * -1 + 99
u,h -> u,i / 0.5 -> 0.0 : ( 0.5 - 0.5)
l,h -> u,i / 99.5 -> 0.0 : (99.5 - 0.5) * -1 + 99
l,h -> l,i / 99.5 -> 99.0 : (99.5 - 0.5)
---
src/mesa/state_tracker/st_mesa_to_tgsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index c07739f..6a63a39 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -883,7 +883,7 @@ emit_wpos(struct st_context *st,
ureg_property_fs_coord_pixel_center(ureg,
TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
else if (pscreen->get_param(pscreen,
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER))
/* the driver supports pixel center half integer, need to bias X,Y */
- emit_adjusted_wpos(t, program, 0.5f, invert ? 0.5f : -0.5f);
+ emit_adjusted_wpos(t, program, -0.5f, -0.5f);
else
assert(0);
}
@@ -891,6 +891,10 @@ emit_wpos(struct st_context *st,
/* Fragment shader wants pixel center half integer */
if (pscreen->get_param(pscreen,
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER)) {
/* the driver supports pixel center half integer */
+ if (invert) {
+/* for h = 100: (0.5 -> 99.5) by ((0.5 - 1.0) * -1 + 99.0) */
+emit_adjusted_wpos(t, program, 0.0f, -1.0f);
+ }
}
else if (pscreen->get_param(pscreen,
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER)) {
/* the driver supports pixel center integer, need to bias X,Y */
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36282] glxgears segfault with swrast
https://bugs.freedesktop.org/show_bug.cgi?id=36282 --- Comment #4 from Alexandre Demers 2011-04-16 09:53:28 PDT --- I forgot to mention I'm running kernel 2.6.39-rc3 and libdrm 2.6.25 (latest) on a 64 bit OS. -- 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: expose ARB_draw_instanced only if EXT_gpu_shader4 is available too
On Sun, Apr 17, 2011 at 12:18 AM, Brian Paul wrote: > On Sat, Apr 16, 2011 at 5:06 AM, Marek Olšák wrote: >> From GL_ARB_draw_instanced: >> >> EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required. >> >> which means we can't advertise it. :( Well at least apps won't be looking >> for gl_InstanceID. > > I believe that the GL_ARB_draw_instanced spec is wrong about that. > There's really no reason why instancing depends on those extensions. I > think that Ian has reported this issue along with gl_InstanceID vs. > gl_InstanceIDARB to the ARB so the spec may be changed soon. > > Typically, ARB extensions do not directly depend on EXT extensions. > But they can depend on GL major versions, so in this case I assume that piece about GL3.0 applies. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36307] New: libGL segfault with gnome-shell/mutter (using intel-dri)
https://bugs.freedesktop.org/show_bug.cgi?id=36307
Summary: libGL segfault with gnome-shell/mutter (using
intel-dri)
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: GLX
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: d...@tzib.net
Description:
gnome-shell (and thus) mutter --replace crashes. kernel reports the segfault
being located in libGL (in glx code)
gnome-shell[27096]: segfault at 28 ip 7f253f36fe37 sp 7fffdb130f60
error 6 in libGL.so.1.2[7f253f323000+6b000]
Additional info (all versions, from archlinux 64 bit - note the GIT version
snapshots including the date of the snapshopt):
* gnome-shell 3.0.0.2-2
* mutter 3.0.0-1
* mesa 7.10.99.git20110412-1
* libgl 7.10.99.git20110412-1
* intel-dri 7.10.99.git20110412-1
* libdrm 2.4.25-1
* xf86-video-intel 2.15.0-1
* kernel26 2.6.38.2-1
Hardware:
* Intel Ironlake mobile:
VGA compatible controller: Intel Corporation Core Processor Integrated Graphics
Controller (rev 02) (prog-if 00 [VGA controller])
Steps to reproduce:
Install GNOME-3 from testing (archlinux)
Start gnome-shell --replace or mutter --replace or set your default GNOME3
graphic experience to default (not fallback)
Program received signal SIGSEGV, Segmentation fault.
0x722b424a in ChangeDrawableAttribute (dpy=0x61b0f0, drawable=56623113,
attribs=0x7fffdf20, num_attribs=1)
at glx_pbuffer.c:144
144 pdraw->eventMask = attribs[i * 2 + 1];
(gdb) bt
#0 0x722b424a in ChangeDrawableAttribute (dpy=0x61b0f0,
drawable=56623113, attribs=0x7fffdf20, num_attribs=1)
at glx_pbuffer.c:144
#1 0x722b56a8 in glXSelectEvent (dpy=0x61b0f0, drawable=56623113,
mask=67108864) at glx_pbuffer.c:794
(gdb) l *0x722b424a
0x722b424a is in ChangeDrawableAttribute (glx_pbuffer.c:144).
139
140 for (i = 0; i < num_attribs; i++) {
141 switch(attribs[i * 2]) {
142 case GLX_EVENT_MASK:
143 /* Keep a local copy for masking out DRI2 proto events as needed */
144 pdraw->eventMask = attribs[i * 2 + 1];
145 break;
146 }
147 }
148 #endif
(gdb) print pdraw
$1 = (__GLXDRIdrawable *) 0x0
(gdb) print pdraw->eventMask
Cannot access memory at address 0x28
(gdb) print i
$2 = 0
(gdb) print num_attribs
$3 = 1
Original source:
#ifdef GLX_DIRECT_RENDERING
pdraw = GetGLXDRIDrawable(dpy, drawable);
for (i = 0; i < num_attribs; i++) {
switch(attribs[i * 2]) {
case GLX_EVENT_MASK:
/* Keep a local copy for masking out DRI2 proto events as needed */
pdraw->eventMask = attribs[i * 2 + 1];
break;
}
}
#endif
inside the definition of what gets pdraw and return NULL (0x0):
/**
* Get the __DRIdrawable for the drawable associated with a GLXContext
*
* \param dpy The display associated with \c drawable.
* \param drawable GLXDrawable whose __DRIdrawable part is to be retrieved.
* \param scrn_num If non-NULL, the drawables screen is stored there
* \returns A pointer to the context's __DRIdrawable on success, or NULL if
* the drawable is not associated with a direct-rendering context.
*/
_X_HIDDEN __GLXDRIdrawable *
GetGLXDRIDrawable(Display * dpy, GLXDrawable drawable)
{
struct glx_display *priv = __glXInitialize(dpy);
__GLXDRIdrawable *pdraw;
if (priv == NULL)
return NULL;
if (__glxHashLookup(priv->drawHash, drawable, (void *) &pdraw) == 0)
return pdraw;
return NULL;
}
See also https://bugs.archlinux.org/task/23788
--
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 36307] libGL segfault with gnome-shell/mutter (using intel-dri)
https://bugs.freedesktop.org/show_bug.cgi?id=36307 d...@tzib.net changed: What|Removed |Added Platform|Other |x86-64 (AMD64) OS/Version|All |Linux (All) -- 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] [PATCH] gallium: include u_format.h for util_format_is_supported
Without it gcc complains: nv50_screen.c: In function ‘nv50_screen_is_format_supported’: nv50_screen.c:48: warning: implicit declaration of function ‘util_format_is_supported’ and handles it wrongly - util_format_is_supported returns boolean, which is typedef'ed to uchar, but function without prototype is assumed to return int. For me nv50_screen_is_format_supported was returning true for float formats without --enable-texture-float... --- src/gallium/drivers/i915/i915_screen.c |1 + src/gallium/drivers/i965/brw_screen.c |1 + src/gallium/drivers/nv50/nv50_screen.c |1 + src/gallium/drivers/nvc0/nvc0_screen.c |1 + src/gallium/drivers/nvfx/nvfx_screen.c |1 + src/gallium/drivers/r600/r600_pipe.c |1 + 6 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 6f6a342..0f4327f 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -27,6 +27,7 @@ #include "draw/draw_context.h" +#include "util/u_format.h" #include "util/u_inlines.h" #include "util/u_memory.h" #include "util/u_string.h" diff --git a/src/gallium/drivers/i965/brw_screen.c b/src/gallium/drivers/i965/brw_screen.c index 5353ae2..9178dfa 100644 --- a/src/gallium/drivers/i965/brw_screen.c +++ b/src/gallium/drivers/i965/brw_screen.c @@ -26,6 +26,7 @@ **/ +#include "util/u_format.h" #include "util/u_inlines.h" #include "util/u_memory.h" #include "util/u_string.h" diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c index e0eea3e..641ad7e 100644 --- a/src/gallium/drivers/nv50/nv50_screen.c +++ b/src/gallium/drivers/nv50/nv50_screen.c @@ -20,6 +20,7 @@ * SOFTWARE. */ +#include "util/u_format.h" #include "util/u_format_s3tc.h" #include "pipe/p_screen.h" diff --git a/src/gallium/drivers/nvc0/nvc0_screen.c b/src/gallium/drivers/nvc0/nvc0_screen.c index c4cdfac..5325807 100644 --- a/src/gallium/drivers/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nvc0/nvc0_screen.c @@ -20,6 +20,7 @@ * SOFTWARE. */ +#include "util/u_format.h" #include "util/u_format_s3tc.h" #include "pipe/p_screen.h" diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c b/src/gallium/drivers/nvfx/nvfx_screen.c index abbed96..ab063d6 100644 --- a/src/gallium/drivers/nvfx/nvfx_screen.c +++ b/src/gallium/drivers/nvfx/nvfx_screen.c @@ -1,5 +1,6 @@ #include "pipe/p_screen.h" #include "pipe/p_state.h" +#include "util/u_format.h" #include "util/u_format_s3tc.h" #include "util/u_simple_screen.h" diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 066768f..1a581c7 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -30,6 +30,7 @@ #include #include #include +#include "util/u_format.h" #include #include #include -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: include u_format.h for util_format_is_supported
Pushed, thanks. Marek On Sat, Apr 16, 2011 at 10:15 PM, Marcin Slusarz wrote: > Without it gcc complains: > nv50_screen.c: In function ‘nv50_screen_is_format_supported’: > nv50_screen.c:48: warning: implicit declaration of function > ‘util_format_is_supported’ > > and handles it wrongly - util_format_is_supported returns boolean, which is > typedef'ed > to uchar, but function without prototype is assumed to return int. > > For me nv50_screen_is_format_supported was returning true for float formats > without > --enable-texture-float... > --- > src/gallium/drivers/i915/i915_screen.c |1 + > src/gallium/drivers/i965/brw_screen.c |1 + > src/gallium/drivers/nv50/nv50_screen.c |1 + > src/gallium/drivers/nvc0/nvc0_screen.c |1 + > src/gallium/drivers/nvfx/nvfx_screen.c |1 + > src/gallium/drivers/r600/r600_pipe.c |1 + > 6 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/src/gallium/drivers/i915/i915_screen.c > b/src/gallium/drivers/i915/i915_screen.c > index 6f6a342..0f4327f 100644 > --- a/src/gallium/drivers/i915/i915_screen.c > +++ b/src/gallium/drivers/i915/i915_screen.c > @@ -27,6 +27,7 @@ > > > #include "draw/draw_context.h" > +#include "util/u_format.h" > #include "util/u_inlines.h" > #include "util/u_memory.h" > #include "util/u_string.h" > diff --git a/src/gallium/drivers/i965/brw_screen.c > b/src/gallium/drivers/i965/brw_screen.c > index 5353ae2..9178dfa 100644 > --- a/src/gallium/drivers/i965/brw_screen.c > +++ b/src/gallium/drivers/i965/brw_screen.c > @@ -26,6 +26,7 @@ > > **/ > > > +#include "util/u_format.h" > #include "util/u_inlines.h" > #include "util/u_memory.h" > #include "util/u_string.h" > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > b/src/gallium/drivers/nv50/nv50_screen.c > index e0eea3e..641ad7e 100644 > --- a/src/gallium/drivers/nv50/nv50_screen.c > +++ b/src/gallium/drivers/nv50/nv50_screen.c > @@ -20,6 +20,7 @@ > * SOFTWARE. > */ > > +#include "util/u_format.h" > #include "util/u_format_s3tc.h" > #include "pipe/p_screen.h" > > diff --git a/src/gallium/drivers/nvc0/nvc0_screen.c > b/src/gallium/drivers/nvc0/nvc0_screen.c > index c4cdfac..5325807 100644 > --- a/src/gallium/drivers/nvc0/nvc0_screen.c > +++ b/src/gallium/drivers/nvc0/nvc0_screen.c > @@ -20,6 +20,7 @@ > * SOFTWARE. > */ > > +#include "util/u_format.h" > #include "util/u_format_s3tc.h" > #include "pipe/p_screen.h" > > diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c > b/src/gallium/drivers/nvfx/nvfx_screen.c > index abbed96..ab063d6 100644 > --- a/src/gallium/drivers/nvfx/nvfx_screen.c > +++ b/src/gallium/drivers/nvfx/nvfx_screen.c > @@ -1,5 +1,6 @@ > #include "pipe/p_screen.h" > #include "pipe/p_state.h" > +#include "util/u_format.h" > #include "util/u_format_s3tc.h" > #include "util/u_simple_screen.h" > > diff --git a/src/gallium/drivers/r600/r600_pipe.c > b/src/gallium/drivers/r600/r600_pipe.c > index 066768f..1a581c7 100644 > --- a/src/gallium/drivers/r600/r600_pipe.c > +++ b/src/gallium/drivers/r600/r600_pipe.c > @@ -30,6 +30,7 @@ > #include > #include > #include > +#include "util/u_format.h" > #include > #include > #include > -- > 1.7.4.1 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: expose ARB_draw_instanced only if EXT_gpu_shader4 is available too
The patch actually fixes every app which dares to use ARB_draw_instanced. The only apps the very presence of the extension doesn't break are piglit tests. It's clear from bug reports that not only is the current implementation of the extension absolutely useless in reality, it also prevents users from using certain apps (isn't it great?). The standard is worthless if it doesn't let you be compatible with the rest of the world and, it this case, it sort of does by this line: EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required. Well there certainly is a reason it depends on EXT_gpu_shader4: gl_InstanceID. And it nicely matches the reality. I don't insist on committing the patch, I can disable the extension from a driver. However I thought other drivers would need the same fix. Marek On Sat, Apr 16, 2011 at 4:18 PM, Brian Paul wrote: > On Sat, Apr 16, 2011 at 5:06 AM, Marek Olšák wrote: > > From GL_ARB_draw_instanced: > > > >EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required. > > > > which means we can't advertise it. :( Well at least apps won't be looking > > for gl_InstanceID. > > I believe that the GL_ARB_draw_instanced spec is wrong about that. > There's really no reason why instancing depends on those extensions. I > think that Ian has reported this issue along with gl_InstanceID vs. > gl_InstanceIDARB to the ARB so the spec may be changed soon. > > Typically, ARB extensions do not directly depend on EXT extensions. > > -Brian > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: expose ARB_draw_instanced only if EXT_gpu_shader4 is available too
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2011 04:06 AM, Marek Olšák wrote: > From GL_ARB_draw_instanced: > > EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required. > > which means we can't advertise it. :( Well at least apps won't be looking > for gl_InstanceID. The GL_ARB_draw_instanced spec is broken. I've already mentioned a couple times in e-mail and in bugs that it's in the process of getting fixed. Everyone needs to just chill. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2qRh4ACgkQX1gOwKyEAw/NuACfQyoVTBIzzSCUfRFYa4e95ayR /rQAn0lLwSClB5FM9Yj4pnUuMPrhU8LC =T4/t -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36295] Incorrect rendering in SPECviewperf benchmark
https://bugs.freedesktop.org/show_bug.cgi?id=36295 --- Comment #3 from Ian Romanick 2011-04-16 18:49:14 PDT --- (In reply to comment #2) > This is a bug in SPECviewperf11, which relies on NV_fragment_program2 > extension, even when it is not advertised. > > Me and Brian have a patch that workarounds this by tolerating > NV_fragment_program2 's IF/ELSE/ENDIF opcodes. > > This is exactly the same stratergy that AMD's fglrx drivers took: not > advertise > NVIDIA's extension, but silently handle it. Oh hell no. Report this bug to spec. Seriously. Issues of differing names of instance ID is one thing, but giant piles of functionality is completely different. This is a MAJOR bug in viewperf. It needs to be reported to them, and they need to fix it. Period. -- 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 36295] Incorrect rendering in SPECviewperf benchmark
https://bugs.freedesktop.org/show_bug.cgi?id=36295 --- Comment #4 from Ian Romanick 2011-04-16 18:52:21 PDT --- Wait... None of the Intel drivers expose that NVIDIA extension either. Why is rendering correct there but not on r600g? It seems unlikely that it's because of GL_NV_fragment_program2. -- 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 36295] Incorrect rendering in SPECviewperf benchmark
https://bugs.freedesktop.org/show_bug.cgi?id=36295 Ian Romanick 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
Re: [Mesa-dev] [PATCH] st/mesa: expose ARB_draw_instanced only if EXT_gpu_shader4 is available too
On Sun, Apr 17, 2011 at 11:45 AM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/16/2011 04:06 AM, Marek Olšák wrote: >> From GL_ARB_draw_instanced: >> >> EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required. >> >> which means we can't advertise it. :( Well at least apps won't be looking >> for gl_InstanceID. > > The GL_ARB_draw_instanced spec is broken. I've already mentioned a > couple times in e-mail and in bugs that it's in the process of getting > fixed. Everyone needs to just chill. I expect the problem is fixing the spec post-release isn't going to fix all the apps that abide by the older version of the spec. If what Marek says is true, then apps expect GL3.0 or EXT_gpu_shader4 if they have ARB_draw_instanced. Unless changing the spec includes moving the bits of EXT_gpu_shader4 into the ARB_draw_instanced spec, if so then maybe it'll all be fine. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] dri: Remove driver date from renderer string
On Mon, Apr 4, 2011 at 4:48 PM, Ian Romanick wrote: > From: Ian Romanick > > --- > src/mesa/drivers/dri/common/utils.c | 5 ++--- > src/mesa/drivers/dri/common/utils.h | 2 +- > src/mesa/drivers/dri/i810/i810context.c | 4 +--- > src/mesa/drivers/dri/intel/intel_context.c | 6 +- > src/mesa/drivers/dri/mach64/mach64_dd.c | 5 + > src/mesa/drivers/dri/mga/mgadd.c | 4 > src/mesa/drivers/dri/nouveau/nouveau_driver.c | 2 +- > src/mesa/drivers/dri/nouveau/nouveau_driver.h | 1 - > src/mesa/drivers/dri/r128/r128_dd.c | 6 +- > src/mesa/drivers/dri/r200/r200_context.c | 5 + > .../drivers/dri/radeon/radeon_common_context.c | 5 + > src/mesa/drivers/dri/radeon/radeon_context.c | 2 -- > src/mesa/drivers/dri/savage/savagedd.c | 4 +--- > src/mesa/drivers/dri/sis/sis_dd.c | 4 +--- > src/mesa/drivers/dri/tdfx/tdfx_dd.c | 5 + > src/mesa/drivers/dri/unichrome/via_context.c | 4 +--- > 16 files changed, 14 insertions(+), 50 deletions(-) > Turns out there was a bit of fallout from this in kwin, specifically the intel portion that was pushed to the stable branch in b0a7492aebeb4517346f0da2362d6991a7385b59. http://bugs.kde.org/show_bug.cgi?id=270942 Also, at one point they actually used the driver date in their blacklists, I'm not sure if they are still doing that though. -Robert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r200: enable EXT_gpu_program_parameters
On Sat, Apr 16, 2011 at 6:01 AM, Nicolas Kaiser wrote: > Signed-off-by: Nicolas Kaiser > --- > According to Marek Olšák, this extension is quite popular in > the GL community.[1] > > Tests look good: > ./src/tests/prog_parameter > GL_RENDERER = Mesa DRI R200 (R200 514D) TCL DRI2 > GL_VERSION = 1.3 Mesa 7.11-devel (git-4ee40c3) > > GL_EXT_gpu_program_parameters available, testing that path. > Testing glProgramEnvParameter4fvARB (count = 256)... > Testing glProgramEnvParameters4fvEXT (count = 256)... > Testing glProgramLocalParameter4fvARB (count = 1024)... > Testing glProgramLocalParameters4fvEXT (count = 1024)... > PASS! > > Best regards, > Nicolas Kaiser > > [1] http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12980.html > R200 hw doesn't support shader program (well what i wouldn't call what r200 has a shader). Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r200: enable EXT_gpu_program_parameters
r200 does support ARB_vertex_program. The backend is in r200_vertprog.c. I think it has vertex shader 1.1 in D3D. The patch is wrong though. The extension should be listed in the ARB_vp_extension array, not card_extensions. Marek On Sun, Apr 17, 2011 at 4:57 AM, Jerome Glisse wrote: > On Sat, Apr 16, 2011 at 6:01 AM, Nicolas Kaiser wrote: > > Signed-off-by: Nicolas Kaiser > > --- > > According to Marek Olšák, this extension is quite popular in > > the GL community.[1] > > > > Tests look good: > > ./src/tests/prog_parameter > > GL_RENDERER = Mesa DRI R200 (R200 514D) TCL DRI2 > > GL_VERSION = 1.3 Mesa 7.11-devel (git-4ee40c3) > > > > GL_EXT_gpu_program_parameters available, testing that path. > > Testing glProgramEnvParameter4fvARB (count = 256)... > > Testing glProgramEnvParameters4fvEXT (count = 256)... > > Testing glProgramLocalParameter4fvARB (count = 1024)... > > Testing glProgramLocalParameters4fvEXT (count = 1024)... > > PASS! > > > > Best regards, > > Nicolas Kaiser > > > > [1] > http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12980.html > > > > R200 hw doesn't support shader program (well what i wouldn't call what > r200 has a shader). > > Cheers, > Jerome > ___ > 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
