Re: [Mesa-dev] GLSL compiler produces different code for the same source
On 03/30/2012 02:11 PM, Vadim Girlin wrote: Hi, I noticed that GLSL compiler sometimes produces different code for the same shader source, e.g.: Vertex shader source: gl_Position = gl_Vertex; gl_FrontColor = gl_Vertex; GLSL IR: (assign (xyzw) (var_ref gl_Position) (var_ref gl_Vertex) ) (assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Vertex) ) (assign (xyzw) (var_ref gl_Position@2) (var_ref gl_Position) ) (assign (xyzw) (var_ref gl_FrontColor@3) (var_ref gl_FrontColor) ) Another variant has another order of the last two assignments: (assign (xyzw) (var_ref gl_FrontColor@4) (var_ref gl_FrontColor) ) (assign (xyzw) (var_ref gl_Position@5) (var_ref gl_Position) ) Both variants are correct, but it makes the debugging harder - e.g. one of the variants uncovers the bug in my code, and it's hard to reproduce it. I guess we might want to remove the dependency on the moon phase etc, and maybe provide some way to control it for debugging. My knowledge of the GLSL compiler is still not good enough to fix it quickly, so I'd be grateful if somebody could help. There is the reduced test program in the attachment that demonstrates the problem. It compiles the shader every second, so running it with the following command line usually shows both variants during the first 10 seconds: MESA_GLSL=dump ./test | grep -A 20 linked Vadim Weird...I have no idea why it would do that. So far, I haven't been able to reproduce this locally, either with your test program, glslparsertest, or the standalone compiler. Valgrind doesn't seem to have any complaints about uninitialized data, either... Can anyone else reproduce this? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Woes of --enable-32-bit on x86-64 Fedora 15
On 03/30/2012 09:31 AM, Ian Romanick wrote: Building the i965 driver with --enable-32-bit is just broken on Fedora 15. It seems to work for folks on other distros, but I get a lot of failure during linking i965_dri.so. Linking i915_dri.so works, and the difference seems to be the presence of C++ files in i965. I'm not sure what the deal is with F15. It works quite well on F16 and Arch with: git clean -fdx; CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --enable-gles2 --enable-gles1 --disable-glu --with-gallium-drivers= --with-dri-drivers=swrast,i965 --enable-texture-float --enable-debug --enable-shared-glapi --enable-glx-tls --enable-32-bit; make -j5 I've never had to use host options or linux32/setarch... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL compiler produces different code for the same source
On Sat, Mar 31, 2012 at 12:02:42AM -0700, Kenneth Graunke wrote: > On 03/30/2012 02:11 PM, Vadim Girlin wrote: > > Hi, > > > > I noticed that GLSL compiler sometimes produces different code for the > > same shader source, e.g.: > > > > Vertex shader source: > > > >>gl_Position = gl_Vertex; > >>gl_FrontColor = gl_Vertex; > > > > GLSL IR: > > > >>(assign (xyzw) (var_ref gl_Position) (var_ref gl_Vertex) ) > >>(assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Vertex) ) > >>(assign (xyzw) (var_ref gl_Position@2) (var_ref gl_Position) ) > >>(assign (xyzw) (var_ref gl_FrontColor@3) (var_ref gl_FrontColor) ) > > > > Another variant has another order of the last two assignments: > > > >>(assign (xyzw) (var_ref gl_FrontColor@4) (var_ref gl_FrontColor) ) > >>(assign (xyzw) (var_ref gl_Position@5) (var_ref gl_Position) ) > > > > Both variants are correct, but it makes the debugging harder - e.g. one > > of the variants uncovers the bug in my code, and it's hard to reproduce > > it. I guess we might want to remove the dependency on the moon phase > > etc, and maybe provide some way to control it for debugging. > > > > My knowledge of the GLSL compiler is still not good enough to fix it > > quickly, so I'd be grateful if somebody could help. > > > > There is the reduced test program in the attachment that demonstrates > > the problem. It compiles the shader every second, so running it with the > > following command line usually shows both variants during the first 10 > > seconds: > > > >> MESA_GLSL=dump ./test | grep -A 20 linked > > > > Vadim > > Weird...I have no idea why it would do that. > > So far, I haven't been able to reproduce this locally, either with your > test program, glslparsertest, or the standalone compiler. Valgrind > doesn't seem to have any complaints about uninitialized data, either... > > Can anyone else reproduce this? I was able to reproduce this with r300g. Is it possible that one of the shader CAPS is causing this? -Tom > ___ > 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] GLSL compiler produces different code for the same source
On Sat, Mar 31, 2012 at 06:25:08AM -0400, Tom Stellard wrote: > On Sat, Mar 31, 2012 at 12:02:42AM -0700, Kenneth Graunke wrote: > > On 03/30/2012 02:11 PM, Vadim Girlin wrote: > > > Hi, > > > > > > I noticed that GLSL compiler sometimes produces different code for the > > > same shader source, e.g.: > > > > > > Vertex shader source: > > > > > >> gl_Position = gl_Vertex; > > >> gl_FrontColor = gl_Vertex; > > > > > > GLSL IR: > > > > > >>(assign (xyzw) (var_ref gl_Position) (var_ref gl_Vertex) ) > > >>(assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Vertex) ) > > >>(assign (xyzw) (var_ref gl_Position@2) (var_ref gl_Position) ) > > >>(assign (xyzw) (var_ref gl_FrontColor@3) (var_ref > > >> gl_FrontColor) ) > > > > > > Another variant has another order of the last two assignments: > > > > > >>(assign (xyzw) (var_ref gl_FrontColor@4) (var_ref > > >> gl_FrontColor) ) > > >>(assign (xyzw) (var_ref gl_Position@5) (var_ref gl_Position) ) > > > > > > Both variants are correct, but it makes the debugging harder - e.g. one > > > of the variants uncovers the bug in my code, and it's hard to reproduce > > > it. I guess we might want to remove the dependency on the moon phase > > > etc, and maybe provide some way to control it for debugging. > > > > > > My knowledge of the GLSL compiler is still not good enough to fix it > > > quickly, so I'd be grateful if somebody could help. > > > > > > There is the reduced test program in the attachment that demonstrates > > > the problem. It compiles the shader every second, so running it with the > > > following command line usually shows both variants during the first 10 > > > seconds: > > > > > >> MESA_GLSL=dump ./test | grep -A 20 linked > > > > > > Vadim > > > > Weird...I have no idea why it would do that. > > > > So far, I haven't been able to reproduce this locally, either with your > > test program, glslparsertest, or the standalone compiler. Valgrind > > doesn't seem to have any complaints about uninitialized data, either... > > > > Can anyone else reproduce this? > > I was able to reproduce this with r300g. Is it possible that one of the > shader CAPS is causing this? Or maybe the ordering of keys in a hash? > > -Tom > > > ___ > > 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/11] gallium: Basic compute interface.
Marek Olšák writes:
> On Fri, Mar 23, 2012 at 1:40 AM, Francisco Jerez
> wrote:
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index aaeeb81..de990fe 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -63,6 +63,7 @@ struct pipe_vertex_element;
>> struct pipe_video_buffer;
>> struct pipe_video_decoder;
>> struct pipe_viewport_state;
>> +struct pipe_compute_state;
>> union pipe_color_union;
>>
>> /**
>> @@ -140,6 +141,9 @@ struct pipe_context {
>> void (*bind_geometry_sampler_states)(struct pipe_context *,
>> unsigned num_samplers,
>> void **samplers);
>> + void (*bind_compute_sampler_states)(struct pipe_context *,
>> + unsigned num_samplers,
>> + void **samplers);
>
> Hi,
>
Hi,
> could you please add an "unsigned start_slot" parameter in
> bind_compute_sampler_states? The function would then look like this:
>
> void (*bind_compute_sampler_states)(struct pipe_context *,
> unsigned start_slot,
> unsigned num_samplers,
> void **samplers);
>
> Where start_slot+num_samplers <= max_samplers, and max_samplers =
> get(SHADER_CAP_MAX_TEXTURE_SAMPLERS).
>
> The reason for this is that state changes will be faster if you only
> need to change a subset of the bound states (less work for the pipe
> driver).
This sounds reasonable to me. I'll make that change on the three entry
points and resend later today.
> The disadvantage is that the states will have to be unbound
> using something like this:
>
> void *null_ptrs[MAX_SAMPLERS] = {NULL};
> bind_compute_sampler_states(pipe, 0, max_samplers, null_ptrs);
>
Another option would be to take 'samplers == NULL' as meaning that the
specified slot range has to be unbound, e.g.:
| bind_compute_sampler_states(pipe, 0, max_samplers, NULL);
To keep things as simple as possible in the driver we could add the
restriction that no 'samplers[i]' will ever be NULL in cases where
samplers is non-NULL. The usefulness of being able to bind and unbind
states at the same time with the same call is quite dubious anyway...
> I am aware that the other functions don't have the start_slot
> parameter and I'd like to update them so that they do (I have started
> reworking set_vertex_buffers), but that will be a lot of work. In the
> case of compute, where the interface hasn't landed yet, it would be
> wise to add start_slot as soon as possible, so that we don't have to
> rewrite drivers for it later on.
>
>[...]
pgpNvs8Zm5bgm.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/11] gallium: Basic compute interface.
On Sat, Mar 31, 2012 at 2:29 PM, Francisco Jerez wrote:
> Marek Olšák writes:
>
>> On Fri, Mar 23, 2012 at 1:40 AM, Francisco Jerez
>> wrote:
>>> diff --git a/src/gallium/include/pipe/p_context.h
>>> b/src/gallium/include/pipe/p_context.h
>>> index aaeeb81..de990fe 100644
>>> --- a/src/gallium/include/pipe/p_context.h
>>> +++ b/src/gallium/include/pipe/p_context.h
>>> @@ -63,6 +63,7 @@ struct pipe_vertex_element;
>>> struct pipe_video_buffer;
>>> struct pipe_video_decoder;
>>> struct pipe_viewport_state;
>>> +struct pipe_compute_state;
>>> union pipe_color_union;
>>>
>>> /**
>>> @@ -140,6 +141,9 @@ struct pipe_context {
>>> void (*bind_geometry_sampler_states)(struct pipe_context *,
>>> unsigned num_samplers,
>>> void **samplers);
>>> + void (*bind_compute_sampler_states)(struct pipe_context *,
>>> + unsigned num_samplers,
>>> + void **samplers);
>>
>> Hi,
>>
> Hi,
>
>> could you please add an "unsigned start_slot" parameter in
>> bind_compute_sampler_states? The function would then look like this:
>>
>> void (*bind_compute_sampler_states)(struct pipe_context *,
>> unsigned start_slot,
>> unsigned num_samplers,
>> void **samplers);
>>
>> Where start_slot+num_samplers <= max_samplers, and max_samplers =
>> get(SHADER_CAP_MAX_TEXTURE_SAMPLERS).
>>
>> The reason for this is that state changes will be faster if you only
>> need to change a subset of the bound states (less work for the pipe
>> driver).
>
> This sounds reasonable to me. I'll make that change on the three entry
> points and resend later today.
>
>> The disadvantage is that the states will have to be unbound
>> using something like this:
>>
>> void *null_ptrs[MAX_SAMPLERS] = {NULL};
>> bind_compute_sampler_states(pipe, 0, max_samplers, null_ptrs);
>>
> Another option would be to take 'samplers == NULL' as meaning that the
> specified slot range has to be unbound, e.g.:
>
> | bind_compute_sampler_states(pipe, 0, max_samplers, NULL);
>
> To keep things as simple as possible in the driver we could add the
> restriction that no 'samplers[i]' will ever be NULL in cases where
> samplers is non-NULL. The usefulness of being able to bind and unbind
> states at the same time with the same call is quite dubious anyway...
I have kinda already taken the other path with set_vertex_buffers that
null pointers are allowed, but your idea might better. There is
probably not much point in unbinding CSOs (void* states) regularly.
However resources won't be released if they're bound.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] intel: add PCI IDs for Ivy Bridge GT2 server variant
Those IDs are used by Bromolow. Signed-off-by: Eugeni Dodonov --- include/pci_ids/i965_pci_ids.h |1 + src/mesa/drivers/dri/intel/intel_chipset.h |4 +++- src/mesa/drivers/dri/intel/intel_context.c |1 + 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h index a291509..e38f8d2 100644 --- a/include/pci_ids/i965_pci_ids.h +++ b/include/pci_ids/i965_pci_ids.h @@ -25,6 +25,7 @@ CHIPSET(0x0162, IVYBRIDGE_GT2, ivb_gt2) CHIPSET(0x0156, IVYBRIDGE_M_GT1, ivb_gt1) CHIPSET(0x0166, IVYBRIDGE_M_GT2, ivb_gt2) CHIPSET(0x015a, IVYBRIDGE_S_GT1, ivb_gt1) +CHIPSET(0x016a, IVYBRIDGE_S_GT2, ivb_gt2) CHIPSET(0x0402, HASWELL_GT1, hsw_gt1) CHIPSET(0x0412, HASWELL_GT2, hsw_gt2) CHIPSET(0x0406, HASWELL_M_GT1, hsw_gt1) diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h b/src/mesa/drivers/dri/intel/intel_chipset.h index 424c70c..c1d904e 100644 --- a/src/mesa/drivers/dri/intel/intel_chipset.h +++ b/src/mesa/drivers/dri/intel/intel_chipset.h @@ -85,6 +85,7 @@ #define PCI_CHIP_IVYBRIDGE_M_GT10x0156 /* Mobile */ #define PCI_CHIP_IVYBRIDGE_M_GT20x0166 #define PCI_CHIP_IVYBRIDGE_S_GT10x015a /* Server */ +#define PCI_CHIP_IVYBRIDGE_S_GT20x016a #define PCI_CHIP_HASWELL_GT10x0402 /* Desktop */ #define PCI_CHIP_HASWELL_GT20x0412 @@ -153,7 +154,8 @@ devid == PCI_CHIP_IVYBRIDGE_S_GT1) #define IS_IVB_GT2(devid) (devid == PCI_CHIP_IVYBRIDGE_GT2 || \ -devid == PCI_CHIP_IVYBRIDGE_M_GT2) +devid == PCI_CHIP_IVYBRIDGE_M_GT2 || \ +devid == PCI_CHIP_IVYBRIDGE_S_GT2) #define IS_IVYBRIDGE(devid) (IS_IVB_GT1(devid) || IS_IVB_GT2(devid)) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index ff2b7fe..0a813a4 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -183,6 +183,7 @@ intelGetString(struct gl_context * ctx, GLenum name) chipset = "Intel(R) Ivybridge Mobile"; break; case PCI_CHIP_IVYBRIDGE_S_GT1: + case PCI_CHIP_IVYBRIDGE_S_GT2: chipset = "Intel(R) Ivybridge Server"; break; case PCI_CHIP_HASWELL_GT1: -- 1.7.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL compiler produces different code for the same source
On Sat, 2012-03-31 at 06:46 -0400, Tom Stellard wrote: > On Sat, Mar 31, 2012 at 06:25:08AM -0400, Tom Stellard wrote: > > On Sat, Mar 31, 2012 at 12:02:42AM -0700, Kenneth Graunke wrote: > > > On 03/30/2012 02:11 PM, Vadim Girlin wrote: > > > > Hi, > > > > > > > > I noticed that GLSL compiler sometimes produces different code for the > > > > same shader source, e.g.: > > > > > > > > Vertex shader source: > > > > > > > >>gl_Position = gl_Vertex; > > > >>gl_FrontColor = gl_Vertex; > > > > > > > > GLSL IR: > > > > > > > >>(assign (xyzw) (var_ref gl_Position) (var_ref gl_Vertex) ) > > > >>(assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Vertex) ) > > > >>(assign (xyzw) (var_ref gl_Position@2) (var_ref gl_Position) ) > > > >>(assign (xyzw) (var_ref gl_FrontColor@3) (var_ref > > > >> gl_FrontColor) ) > > > > > > > > Another variant has another order of the last two assignments: > > > > > > > >>(assign (xyzw) (var_ref gl_FrontColor@4) (var_ref > > > >> gl_FrontColor) ) > > > >>(assign (xyzw) (var_ref gl_Position@5) (var_ref gl_Position) ) > > > > > > > > Both variants are correct, but it makes the debugging harder - e.g. one > > > > of the variants uncovers the bug in my code, and it's hard to reproduce > > > > it. I guess we might want to remove the dependency on the moon phase > > > > etc, and maybe provide some way to control it for debugging. > > > > > > > > My knowledge of the GLSL compiler is still not good enough to fix it > > > > quickly, so I'd be grateful if somebody could help. > > > > > > > > There is the reduced test program in the attachment that demonstrates > > > > the problem. It compiles the shader every second, so running it with the > > > > following command line usually shows both variants during the first 10 > > > > seconds: > > > > > > > >> MESA_GLSL=dump ./test | grep -A 20 linked > > > > > > > > Vadim > > > > > > Weird...I have no idea why it would do that. > > > > > > So far, I haven't been able to reproduce this locally, either with your > > > test program, glslparsertest, or the standalone compiler. Valgrind > > > doesn't seem to have any complaints about uninitialized data, either... > > > > > > Can anyone else reproduce this? > > > > I was able to reproduce this with r300g. Is it possible that one of the > > shader CAPS is causing this? > > Or maybe the ordering of keys in a hash? > It seems you are right, the output_read_remover stores the mapping of the output variables to the temps in the hash table, using the pointers as the hash. Probably we need to use some other hash function to fix the ordering, e.g. use hash of the variable name? Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 01/11] gallium: Basic compute interface.
Define an interface that exposes the minimal functionality required to implement some of the popular compute APIs. This commit adds entry points to set the grid layout and other state required to keep track of the usual address spaces employed in compute APIs, to bind a compute program, and execute it on the device. --- v2: Add "start slot" argument to the resource binding driver hooks. src/gallium/docs/source/context.rst| 39 +++ src/gallium/docs/source/screen.rst | 28 ++- src/gallium/include/pipe/p_context.h | 73 src/gallium/include/pipe/p_defines.h | 21 +++- src/gallium/include/pipe/p_screen.h| 12 + src/gallium/include/pipe/p_shader_tokens.h |9 src/gallium/include/pipe/p_state.h |7 +++ 7 files changed, 186 insertions(+), 3 deletions(-) diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index b2872cd..7da0aad 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -542,3 +542,42 @@ These flags control the behavior of a transfer object. ``PIPE_TRANSFER_FLUSH_EXPLICIT`` Written ranges will be notified later with :ref:`transfer_flush_region`. Cannot be used with ``PIPE_TRANSFER_READ``. + + +Compute kernel execution + + +A compute program can be defined, bound or destroyed using +``create_compute_state``, ``bind_compute_state`` or +``destroy_compute_state`` respectively. + +Any of the subroutines contained within the compute program can be +executed on the device using the ``launch_grid`` method. This method +will execute as many instances of the program as elements in the +specified N-dimensional grid, hopefully in parallel. + +The compute program has access to four special resources: + +* ``GLOBAL`` represents a memory space shared among all the threads + running on the device. An arbitrary buffer created with the + ``PIPE_BIND_GLOBAL`` flag can be mapped into it using the + ``set_global_binding`` method. + +* ``LOCAL`` represents a memory space shared among all the threads + running in the same working group. The initial contents of this + resource are undefined. + +* ``PRIVATE`` represents a memory space local to a single thread. + The initial contents of this resource are undefined. + +* ``INPUT`` represents a read-only memory space that can be + initialized at ``launch_grid`` time. + +These resources use a byte-based addressing scheme, and they can be +accessed from the compute program by means of the LOAD/STORE TGSI +opcodes. + +In addition, normal texture look-up is allowed from the compute +program: ``bind_compute_sampler_states`` may be used to set up texture +samplers for the compute stage and ``set_compute_sampler_views`` may +be used to bind a number of resources to it. diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 51d9464..6e1877a 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -98,7 +98,8 @@ The integer capabilities: equivalent to a specific GLSL version. E.g. for GLSL 1.3, report 130. * ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION``: Whether quads adhere to the flatshade_first setting in ``pipe_rasterizer_state``. - +* ``PIPE_CAP_COMPUTE``: Whether the implementation supports the + compute entry points defined in pipe_context and pipe_screen. .. _pipe_capf: @@ -174,6 +175,29 @@ to be 0. samplers. +.. _pipe_compute_cap: + +PIPE_COMPUTE_CAP_* +^^ + +Compute-specific capabilities. They can be queried using +pipe_screen::get_compute_param. + +* ``PIPE_COMPUTE_CAP_GRID_DIMENSION``: Number of supported dimensions + for grid and block coordinates. Value type: ``uint64_t``. +* ``PIPE_COMPUTE_CAP_MAX_GRID_SIZE``: Maximum grid size in block + units. Value type: ``uint64_t []``. +* ``PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE``: Maximum block size in thread + units. Value type: ``uint64_t []``. +* ``PIPE_COMPUTE_CAP_MAX_GLOBAL_SIZE``: Maximum size of the GLOBAL + resource. Value type: ``uint64_t``. +* ``PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE``: Maximum size of the LOCAL + resource. Value type: ``uint64_t``. +* ``PIPE_COMPUTE_CAP_MAX_PRIVATE_SIZE``: Maximum size of the PRIVATE + resource. Value type: ``uint64_t``. +* ``PIPE_COMPUTE_CAP_MAX_INPUT_SIZE``: Maximum size of the INPUT + resource. Value type: ``uint64_t``. + .. _pipe_bind: PIPE_BIND_* @@ -211,6 +235,8 @@ resources might be created and handled quite differently. * ``PIPE_BIND_SCANOUT``: A front color buffer or scanout buffer. * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another process. +* ``PIPE_BIND_GLOBAL``: A buffer that can be mapped into the global + address space of a compute program. .. _pipe_usage: diff --git a/src/gallium/include/pipe/p_context.h b/src/gallium/include/pipe/p_context.h index aaeeb81..fc3f723 100644 --- a/src/galli
[Mesa-dev] [PATCH] glsl: fix variable ordering in the output_read_remover
Use the hash of the variable name string instead of the pointer value.
Signed-off-by: Vadim Girlin
---
This patch solves the problem for me, afaics.
Tested with quick-driver.tests
src/glsl/lower_output_reads.cpp |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/glsl/lower_output_reads.cpp b/src/glsl/lower_output_reads.cpp
index 415b541..151a09b 100644
--- a/src/glsl/lower_output_reads.cpp
+++ b/src/glsl/lower_output_reads.cpp
@@ -54,11 +54,18 @@ public:
virtual ir_visitor_status visit_leave(class ir_function_signature *);
};
+static unsigned
+hash_table_var_hash(const void *key)
+{
+ ir_variable *var = (ir_variable*) key;
+ return hash_table_string_hash(var->name);
+}
+
output_read_remover::output_read_remover()
{
mem_ctx = ralloc_context(NULL);
replacements =
- hash_table_ctor(0, hash_table_pointer_hash, hash_table_pointer_compare);
+ hash_table_ctor(0, hash_table_var_hash, hash_table_pointer_compare);
}
output_read_remover::~output_read_remover()
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 48141] New: [vmwgfx] src/gallium/auxiliary/util/u_inlines.h:256:pipe_buffer_map_range: Assertion `offset + length <= buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=48141 Bug #: 48141 Summary: [vmwgfx] src/gallium/auxiliary/util/u_inlines.h:256:pipe_buffer _map_range: Assertion `offset + length <= buffer->width0' failed. Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: v...@freedesktop.org mesa: 4123d0b32138a0fbdbc7f61380d041704ba0ad43 (master) Run piglit draw-elements-base-vertex-bounds on vmwgfx. $ ./bin/draw-elements-base-vertex-bounds -auto src/gallium/auxiliary/util/u_inlines.h:256:pipe_buffer_map_range: Assertion `offset + length <= buffer->width0' failed. (gdb) bt #0 0x7fc24eedd7a1 in _debug_assert_fail ( expr=0x7fc24fb2e978 "offset + length <= buffer->width0", file=0x7fc24fb2e900 "src/gallium/auxiliary/util/u_inlines.h", line=256, function=0x7fc24fb2ea80 "pipe_buffer_map_range") at src/gallium/auxiliary/util/u_debug.c:278 #1 0x7fc24eee92a4 in pipe_buffer_map_range (pipe=0x8cbaa0, buffer=0xa652f0, offset=16, length=44, usage=1, transfer=0x7fff2857ad18) at src/gallium/auxiliary/util/u_inlines.h:256 #2 0x7fc24eee9a80 in u_upload_buffer (upload=0x8cabf0, min_out_offset=0, offset=16, size=44, inbuf=0xa652f0, out_offset=0xa65470, outbuf=0xa65468) at src/gallium/auxiliary/util/u_upload_mgr.c:243 #3 0x7fc24ee7c13a in svga_upload_user_buffers (svga=0x8cbaa0, start=1, count=3, instance_count=1) at src/gallium/drivers/svga/svga_pipe_draw.c:149 #4 0x7fc24ee7c30c in retry_draw_range_elements (svga=0x8cbaa0, index_buffer=0xa63f70, index_size=4, index_bias=1, min_index=0, max_index=2, prim=4, start=0, count=3, instance_count=1, do_retry=1 '\001') at src/gallium/drivers/svga/svga_pipe_draw.c:247 #5 0x7fc24ee7c77f in svga_draw_vbo (pipe=0x8cbaa0, info=0x7fff2857aee0) at src/gallium/drivers/svga/svga_pipe_draw.c:391 #6 0x7fc24f98cee7 in st_draw_vbo (ctx=0x985f60, arrays=0x9ffb08, prims=0x7fff2857afd0, nr_prims=1, ib=0x7fff2857afb0, index_bounds_valid=0 '\000', min_index=0, max_index=2, tfb_vertcount=0x0) at src/mesa/state_tracker/st_draw.c:1110 #7 0x7fc24fa2b639 in vbo_validated_drawrangeelements (ctx=0x985f60, mode=4, index_bounds_valid=0 '\000', start=4294967295, end=4294967295, count=3, type=5125, indices=0x7fff2857b0b0, basevertex=1, numInstances=1) at src/mesa/vbo/vbo_exec_array.c:830 #8 0x7fc24fa2bb75 in vbo_exec_DrawElementsBaseVertex (mode=4, count=3, type=5125, indices=0x7fff2857b0b0, basevertex=1) at src/mesa/vbo/vbo_exec_array.c:979 #9 0x00430212 in stub_glDrawElementsBaseVertex (mode=4, count=3, type=5125, indices=0x7fff2857b0b0, basevertex=1) at piglit/tests/util/generated_dispatch.c:5223 #10 0x004254f3 in piglit_display () at piglit/tests/general/draw-elements-base-vertex-bounds.c:107 #11 0x00425cd1 in display () at piglit/tests/util/piglit-framework.c:56 #12 0x7fc252c57220 in fghRedrawWindow (window=0x8b5470) at freeglut_main.c:210 #13 fghcbDisplayWindow (window=0x8b5470, enumerator=0x7fff2857b170) at freeglut_main.c:227 #14 0x7fc252c5a939 in fgEnumWindows ( enumCallback=0x7fc252c57120 , enumerator=0x7fff2857b170) at freeglut_structure.c:394 #15 0x7fc252c5765a in fghDisplayAll () at freeglut_main.c:249 #16 glutMainLoopEvent () at freeglut_main.c:1450 #17 0x7fc252c57f0e in glutMainLoop () at freeglut_main.c:1498 #18 0x0042646e in main (argc=1, argv=0x7fff2857b4c8) at piglit/tests/util/piglit-framework.c:304 (gdb) frame 1 #1 0x7fc24eee92a4 in pipe_buffer_map_range (pipe=0x8cbaa0, buffer=0xa652f0, offset=16, length=44, usage=1, transfer=0x7fff2857ad18) at src/gallium/auxiliary/util/u_inlines.h:256 256 assert(offset + length <= buffer->width0); (gdb) print buffer->width0 $1 = 44 -- 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 48142] New: [vmwgfx] rc/gallium/drivers/svga/svga_tgsi_decl_sm30.c:76:translate_vs_ps_semantic: Assertion `0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=48142
Bug #: 48142
Summary: [vmwgfx]
rc/gallium/drivers/svga/svga_tgsi_decl_sm30.c:76:trans
late_vs_ps_semantic: Assertion `0' failed.
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
mesa: 4123d0b32138a0fbdbc7f61380d041704ba0ad43 (master)
Run piglit clip-plane-transformation clipvert_pos on vmwgfx.
$ ./bin/clip-plane-transformation clipvert_pos -auto
src/gallium/drivers/svga/svga_tgsi_decl_sm30.c:76:translate_vs_ps_semantic:
Assertion `0' failed.
Trace/breakpoint trap (core dumped)
(gdb) bt
#0 0x7f9b5d97a7a1 in _debug_assert_fail (expr=0x7f9b5e5c2e23 "0",
file=0x7f9b5e5c2de0 "src/gallium/drivers/svga/svga_tgsi_decl_sm30.c",
line=76,
function=0x7f9b5e5c2f20 "translate_vs_ps_semantic") at
src/gallium/auxiliary/util/u_debug.c:278
#1 0x7f9b5d931f61 in translate_vs_ps_semantic (emit=0x7fffa489c500,
semantic=...,
usage=0x7fffa489c3b8, idx=0x7fffa489c3bc) at
src/gallium/drivers/svga/svga_tgsi_decl_sm30.c:76
#2 0x7f9b5d932be7 in vs30_output (emit=0x7fffa489c500, semantic=...,
idx=1)
at src/gallium/drivers/svga/svga_tgsi_decl_sm30.c:446
#3 0x7f9b5d93302d in svga_translate_decl_sm30 (emit=0x7fffa489c500,
decl=0x7fffa489c438)
at src/gallium/drivers/svga/svga_tgsi_decl_sm30.c:550
#4 0x7f9b5d92d27e in svga_shader_emit_instructions (emit=0x7fffa489c500,
tokens=0x259d050)
at src/gallium/drivers/svga/svga_tgsi_insn.c:3197
#5 0x7f9b5d925b02 in svga_tgsi_translate (shader=0x259d870, key=...,
unit=0)
at src/gallium/drivers/svga/svga_tgsi.c:302
#6 0x7f9b5d925f17 in svga_translate_vertex_program (vs=0x259d870,
vkey=0x7fffa489d380)
at src/gallium/drivers/svga/svga_tgsi.c:369
#7 0x7f9b5d923bbd in compile_vs (svga=0x2330aa0, vs=0x259d870,
key=0x7fffa489d380,
out_result=0x7fffa489d398) at src/gallium/drivers/svga/svga_state_vs.c:109
#8 0x7f9b5d923e8c in emit_hw_vs (svga=0x2330aa0, dirty=4294967295)
at src/gallium/drivers/svga/svga_state_vs.c:190
#9 0x7f9b5d91cf83 in update_state (svga=0x2330aa0, atoms=0x7f9b5ee3e200,
state=0x23350a0)
at src/gallium/drivers/svga/svga_state.c:154
#10 0x7f9b5d91d1a7 in svga_update_state (svga=0x2330aa0, max_level=2)
at src/gallium/drivers/svga/svga_state.c:209
#11 0x7f9b5d919493 in retry_draw_arrays (svga=0x2330aa0, prim=7, start=0,
count=4, instance_count=1,
do_retry=1 '\001') at src/gallium/drivers/svga/svga_pipe_draw.c:303
#12 0x7f9b5d9197b5 in svga_draw_vbo (pipe=0x2330aa0, info=0x7fffa489d540)
at src/gallium/drivers/svga/svga_pipe_draw.c:404
#13 0x7f9b5e429ee7 in st_draw_vbo (ctx=0x23eaf50, arrays=0x2464af8,
prims=0x7fffa489d610,
nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3,
tfb_vertcount=0x0)
at src/mesa/state_tracker/st_draw.c:1110
#14 0x7f9b5e4c81c6 in vbo_draw_arrays (ctx=0x23eaf50, mode=7, start=0,
count=4, numInstances=1)
at src/mesa/vbo/vbo_exec_array.c:619
#15 0x7f9b5e4c8305 in vbo_exec_DrawArrays (mode=7, start=0, count=4)
at src/mesa/vbo/vbo_exec_array.c:651
#16 0x004317ec in stub_glDrawArrays (mode=7, first=0, count=4)
at piglit/tests/util/generated_dispatch.c:5061
#17 0x0046d92e in piglit_draw_rect (x=-2, y=-2, w=4, h=4)
at piglit/tests/util/piglit-util-gl.c:738
#18 0x00426c09 in measure_effects (desc=0x46fa69 "base behavior", mc=0,
pc=0, md=0, pd=0,
expected=0)
at
piglit/tests/spec/glsl-1.10/execution/clipping/clip-plane-transformation.c:360
#19 0x00426e36 in piglit_display ()
at
piglit/tests/spec/glsl-1.10/execution/clipping/clip-plane-transformation.c:399
#20 0x00427779 in display () at piglit/tests/util/piglit-framework.c:56
#21 0x7f9b616f4220 in fghRedrawWindow (window=0x231a470) at
freeglut_main.c:210
#22 fghcbDisplayWindow (window=0x231a470, enumerator=0x7fffa489d840) at
freeglut_main.c:227
#23 0x7f9b616f7939 in fgEnumWindows (enumCallback=0x7f9b616f4120
,
enumerator=0x7fffa489d840) at freeglut_structure.c:394
#24 0x7f9b616f465a in fghDisplayAll () at freeglut_main.c:249
#25 glutMainLoopEvent () at freeglut_main.c:1450
#26 0x7f9b616f4f0e in glutMainLoop () at freeglut_main.c:1498
#27 0x00427f16 in main (argc=2, argv=0x7fffa489db98)
at piglit/tests/util/piglit-framework.c:304
(gdb) frame 1
#1 0x7f9b5d931f61 in translate_vs_ps_semantic (emit=0x7fffa489c500,
semantic=...,
usage=0x7fffa489c3b8, idx=0x7fffa489c3bc) at
src/gallium/drivers/svga/svga_tgsi_decl_sm30.c:76
76 assert(0);
(gdb) print semantic
$1 = {Name = 14, Index = 0, Padding = 0}
src/gallium/drivers/svga/svga_tgsi_decl_sm30
[Mesa-dev] [Bug 48143] New: [vmwgfx] src/gallium/drivers/svga/svga_tgsi_insn.c:273:get_temp: Assertion `i < 32' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=48143
Bug #: 48143
Summary: [vmwgfx]
src/gallium/drivers/svga/svga_tgsi_insn.c:273:get_temp
: Assertion `i < 32' failed.
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
mesa: 4123d0b32138a0fbdbc7f61380d041704ba0ad43 (master)
Run piglit vs-varying-array-mat3-col-row-rd on vwmgfx.
$ ./bin/shader_runner
tests/spec/glsl-1.10/execution/variable-indexing/vs-varying-array-mat3-col-row-rd.shader_test
-auto
src/gallium/drivers/svga/svga_tgsi_insn.c:273:get_temp: Assertion `i < 32'
failed.
(gdb) bt
#0 0x7f6ac0e187a1 in _debug_assert_fail (expr=0x7f6ac1a5f75f "i < 32",
file=0x7f6ac1a5f538 "src/gallium/drivers/svga/svga_tgsi_insn.c", line=273,
function=0x7f6ac1a5fd1c "get_temp") at
src/gallium/auxiliary/util/u_debug.c:278
#1 0x7f6ac0dc4e4b in get_temp (emit=0x7fffc100cc70) at
src/gallium/drivers/svga/svga_tgsi_insn.c:273
#2 0x7f6ac0dc569d in submit_lrp (emit=0x7fffc100cc70, dst=..., src0=...,
src1=..., src2=...)
at src/gallium/drivers/svga/svga_tgsi_insn.c:570
#3 0x7f6ac0dc62d2 in emit_cmp (emit=0x7fffc100cc70, insn=0x7fffc100cba8)
at src/gallium/drivers/svga/svga_tgsi_insn.c:901
#4 0x7f6ac0dc97e0 in svga_emit_instruction (emit=0x7fffc100cc70,
position=26, insn=0x7fffc100cba8)
at src/gallium/drivers/svga/svga_tgsi_insn.c:2439
#5 0x7f6ac0dcb2d0 in svga_shader_emit_instructions (emit=0x7fffc100cc70,
tokens=0x1011f20)
at src/gallium/drivers/svga/svga_tgsi_insn.c:3208
#6 0x7f6ac0dc3b02 in svga_tgsi_translate (shader=0x1012740, key=...,
unit=0)
at src/gallium/drivers/svga/svga_tgsi.c:302
#7 0x7f6ac0dc3f17 in svga_translate_vertex_program (vs=0x1012740,
vkey=0x7fffc100daf0)
at src/gallium/drivers/svga/svga_tgsi.c:369
#8 0x7f6ac0dc1bbd in compile_vs (svga=0xe65a20, vs=0x1012740,
key=0x7fffc100daf0,
out_result=0x7fffc100db08) at src/gallium/drivers/svga/svga_state_vs.c:109
#9 0x7f6ac0dc1e8c in emit_hw_vs (svga=0xe65a20, dirty=4294967295)
at src/gallium/drivers/svga/svga_state_vs.c:190
#10 0x7f6ac0dbaf83 in update_state (svga=0xe65a20, atoms=0x7f6ac22dc200,
state=0xe6a020)
at src/gallium/drivers/svga/svga_state.c:154
#11 0x7f6ac0dbb1a7 in svga_update_state (svga=0xe65a20, max_level=2)
at src/gallium/drivers/svga/svga_state.c:209
#12 0x7f6ac0db7493 in retry_draw_arrays (svga=0xe65a20, prim=7, start=0,
count=4, instance_count=1,
do_retry=1 '\001') at src/gallium/drivers/svga/svga_pipe_draw.c:303
#13 0x7f6ac0db77b5 in svga_draw_vbo (pipe=0xe65a20, info=0x7fffc100dcb0)
at src/gallium/drivers/svga/svga_pipe_draw.c:404
#14 0x7f6ac18c7ee7 in st_draw_vbo (ctx=0xf1e010, arrays=0xf97bb8,
prims=0x7fffc100dd80, nr_prims=1,
ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3,
tfb_vertcount=0x0)
at src/mesa/state_tracker/st_draw.c:1110
#15 0x7f6ac19661c6 in vbo_draw_arrays (ctx=0xf1e010, mode=7, start=0,
count=4, numInstances=1)
at src/mesa/vbo/vbo_exec_array.c:619
#16 0x7f6ac1966305 in vbo_exec_DrawArrays (mode=7, start=0, count=4)
at src/mesa/vbo/vbo_exec_array.c:651
#17 0x00438824 in stub_glDrawArrays (mode=7, first=0, count=4)
at piglit/tests/util/generated_dispatch.c:5061
#18 0x0047434a in piglit_draw_rect (x=60, y=5, w=10, h=10)
at piglit/tests/util/piglit-util-gl.c:738
#19 0x0042cf78 in piglit_display () at
piglit/tests/shaders/shader_runner.c:
#20 0x0042e7b1 in display () at piglit/tests/util/piglit-framework.c:56
#21 0x7f6ac50a8220 in fghRedrawWindow (window=0xe4f460) at
freeglut_main.c:210
#22 fghcbDisplayWindow (window=0xe4f460, enumerator=0x7fffc100e070) at
freeglut_main.c:227
#23 0x7f6ac50ab939 in fgEnumWindows (enumCallback=0x7f6ac50a8120
,
enumerator=0x7fffc100e070) at freeglut_structure.c:394
#24 0x7f6ac50a865a in fghDisplayAll () at freeglut_main.c:249
#25 glutMainLoopEvent () at freeglut_main.c:1450
#26 0x7f6ac50a8f0e in glutMainLoop () at freeglut_main.c:1498
#27 0x0042ef4e in main (argc=2, argv=0x7fffc100e3c8)
at piglit/tests/util/piglit-framework.c:304
(gdb) frame 1
#1 0x7f6ac0dc4e4b in get_temp (emit=0x7fffc100cc70) at
src/gallium/drivers/svga/svga_tgsi_insn.c:273
273 assert(i < SVGA3D_TEMPREG_MAX);
(gdb) print i
$1 = 32
(gdb) l
268 */
269static INLINE SVGA3dShaderDestToken
270get_temp( struct svga_shader_emitter *emit )
271{
272 int i = emit->nr_hw_temp + emit->internal_temp_count++;
273 assert(i < SVGA3D_TEMPREG_MAX);
274 i = MIN2(i, SVGA3D_TEMPREG_MAX - 1);
275 return dst_register( SVGA3DREG_TEMP, i );
276}
277
--
C
[Mesa-dev] [Bug 48142] [vmwgfx] src/gallium/drivers/svga/svga_tgsi_decl_sm30.c:76:translate_vs_ps_semantic: Assertion `0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=48142 Vinson Lee changed: What|Removed |Added Summary|[vmwgfx]|[vmwgfx] |rc/gallium/drivers/svga/svg |src/gallium/drivers/svga/sv |a_tgsi_decl_sm30.c:76:trans |ga_tgsi_decl_sm30.c:76:tran |late_vs_ps_semantic:|slate_vs_ps_semantic: |Assertion `0' failed. |Assertion `0' failed. -- 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] swrast: Fix memory leaks in blit_linear.
Fixes Coverity resource leak defects.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Vinson Lee
---
src/mesa/swrast/s_blit.c |9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c
index 6d0b889..b0c56a4 100644
--- a/src/mesa/swrast/s_blit.c
+++ b/src/mesa/swrast/s_blit.c
@@ -566,6 +566,9 @@ blit_linear(struct gl_context *ctx,
GL_MAP_READ_BIT | GL_MAP_WRITE_BIT,
&srcMap, &srcRowStride);
if (!srcMap) {
+ free(srcBuffer0);
+ free(srcBuffer1);
+ free(dstBuffer);
_mesa_error(ctx, GL_OUT_OF_MEMORY, "glBlitFramebuffer");
return;
}
@@ -582,6 +585,9 @@ blit_linear(struct gl_context *ctx,
0, 0, readRb->Width, readRb->Height,
GL_MAP_READ_BIT, &srcMap, &srcRowStride);
if (!srcMap) {
+ free(srcBuffer0);
+ free(srcBuffer1);
+ free(dstBuffer);
_mesa_error(ctx, GL_OUT_OF_MEMORY, "glBlitFramebuffer");
return;
}
@@ -590,6 +596,9 @@ blit_linear(struct gl_context *ctx,
GL_MAP_WRITE_BIT, &dstMap, &dstRowStride);
if (!dstMap) {
ctx->Driver.UnmapRenderbuffer(ctx, readRb);
+ free(srcBuffer0);
+ free(srcBuffer1);
+ free(dstBuffer);
_mesa_error(ctx, GL_OUT_OF_MEMORY, "glBlitFramebuffer");
return;
}
--
1.7.9.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
