On 18.11.2014 05:43, Emil Velikov wrote:
Hello all,
As you may have noticed there are only three commits since 10.3.3, which
imho are quite serious of people hitting those issues.
Thus I do plan on releasing 10.3.4 this Friday.
The usual summary with testing & stats will be out on Wednesday, as
From: Dave Airlie
For 1D and 2D arrays we don't want the other coordinates being
offset and affecting where we sample. I wrote this patch 6 months
ago but lost it.
Fixes:
./bin/tex-miplevel-selection textureLodOffset 1DArray
./bin/tex-miplevel-selection textureLodOffset 2DArray
./bin/tex-mipleve
From: Dave Airlie
For 1D and 2D arrays we don't want the other coordinates being
offset and affecting where we sample. I wrote this patch 6 months
ago but lost it.
This fixes at least
./bin/tex-miplevel-selection textureOffset 1DArray
./bin/tex-miplevel-selection textureOffset 2DArray
Signed-of
From: Dave Airlie
Otherwise we seem to lose the split_gs_inputs and try and
pull from an uninitialised register.
fixes 9 texelFetch geom shader tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sr
For values above integer accuracy in floats, val - floor(val) might
actually produce a value greater than 1. For such large floats, it's
reasonable to be imprecise, but it's unreasonable for FRC to return a
value that is not between 0 and 1.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nou
On 18.11.2014 06:42, Marek Olšák wrote:
From: Marek Olšák
Cc: 10.4
Both patches are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Mesa 10.4.0 release candidate 1 is now available for testing. The
current plan is to have an additional release candidate each Friday
until the eventual 10.4.0 release on Friday, Dec 5th.
The tag in the git repository for Mesa 10.4.0-rc1 is 'mesa-10.4.0-rc1'.
As a reminder, with the 10.4 branch n
On 18.11.2014 00:58, Axel Davy wrote:
Implements vblank_mode and throttling, which allows us change default ratio
between framerate and input lag.
Signed-off-by: David Heidelberg
Signed-off-by: Axel Davy
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
On 17.11.2014 23:30, Aaron Watry wrote:
On Mon, Nov 17, 2014 at 1:45 AM, Michel Dänzer wrote:
On 14.11.2014 19:37, Marek Olšák wrote:
surface_destroy should never be called directly, because surfaces have
a reference counter. For unreferencing resources, use
pipe_surface_reference(&pointer, NU
On 17/11/14 15:58, Axel Davy wrote:
> Hi,
>
> Here is last (4th) iteration of Gallium Nine patches.
>
> We have integrated the new feedback we have got and hope
> the status of the serie is good enough now for merge.
>
Just added the remaining r-b/acked-by tags and pushed it to master.
Guys take
On Tue, 18 Nov 2014 02:23:51 +0100, Dave Airlie wrote:
From: Dave Airlie
Some of the geom shader tests produce an empty vertex shader,
on cayman we'd crash in the finaliser because last_cf was NULL.
cayman doesn't need the NOP workaround, so if the code arrives
here with no last_cf, just emi
On Tue, 18 Nov 2014 01:57:13 +0100, Dave Airlie wrote:
From: Dave Airlie
It appears on cayman the TG4 outputs were reordered.
This fixes a lot of piglit tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 15 +++
1 file changed, 11 insertions(+), 4 d
From: Dave Airlie
Some of the geom shader tests produce an empty vertex shader,
on cayman we'd crash in the finaliser because last_cf was NULL.
cayman doesn't need the NOP workaround, so if the code arrives
here with no last_cf, just emit an END.
fixes crashes in a bunch of piglit geom shader t
From: Dave Airlie
It appears on cayman the TG4 outputs were reordered.
This fixes a lot of piglit tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_sha
On 14/11/14 14:39, Emil Velikov wrote:
> Hello all,
>
> This is an old question that I had laying around - why doesn't mesa use
> a more conventional numbering for the development/rc releases ?
>
> Eg.
> mesa 10.4.0-rc1 -> 10.3.99.901
> mesa 10.4.0-rc2 -> 10.3.99.902
> ...
> mesa 10.4.0 -> 10
On Tue, 18 Nov 2014 00:56:38 +0100, Dave Airlie wrote:
From: Dave Airlie
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 23 ++
I will check for patches tomorrow and Wed morning. Then I'll throw
piglit in the mix and let it do it's thing :)
On 17/11/14 22:00, Ilia Mirkin wrote:
> I plan on checking in the multi-layer clear in the presence of
> scissor/color mask fix today or tomorrow, which should fix things for
> llvmpipe
From: Dave Airlie
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-
From: Dave Airlie
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
d
+Laura. This thread is about you.
On Sun 16 Nov 2014, Gustaw Smolarczyk wrote:
Ok. It would be helpful to note the progress in the docs/GL3.txt file.
The overview of ARB_dsa summarizes the difference between it and the
EXT variant, so I understand the undesirability of implementing
EXT_dsa.
Gu
On 17/11/14 20:05, Emil Velikov wrote:
> Henri,
>
> Considering the interface note able, would you say that any new
> implementation towards handling D3D9 in wine is acceptable ? Please note
> that I'm not talking about improving the existing one be that via GL
> extensions or otherwise.
>
> How
I plan on checking in the multi-layer clear in the presence of
scissor/color mask fix today or tomorrow, which should fix things for
llvmpipe and nouveau. IMHO it'd be worth pulling that one in as well.
It's not in yet, but just a heads-up. [Or were you planning on
re-pulling on Wed?]
On Mon, Nov
Reviewed-by: Ilia Mirkin
Ooops, I thought I had caught all of that :(
On Mon, Nov 17, 2014 at 4:42 PM, Brian Paul wrote:
> The sampler_array_size field was added by "mesa/st: add support for
> dynamic sampler offsets". But the field wasn't getting copied in
> the get_pixel_transfer_visitor() o
From: Marek Olšák
Required by Nine. Tested with util_run_tests.
It's added to softpipe, llvmpipe, and r300g/swtcl.
---
src/gallium/auxiliary/draw/draw_context.c | 40 ++
src/gallium/auxiliary/draw/draw_llvm.c | 2 +-
src/gallium/auxiliary/draw/draw_priva
From: Marek Olšák
Cc: 10.4
---
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index d5b27e7..f108282 100644
The sampler_array_size field was added by "mesa/st: add support for
dynamic sampler offsets". But the field wasn't getting copied in
the get_pixel_transfer_visitor() or get_bitmap_visitor() functions.
The count_resources() function then didn't properly compute the
glsl_to_tgsi_visitor::samplers_u
From: Marek Olšák
No known benefit for OpenGL, but it doesn't hurt.
---
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_state_draw.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/
Hello all,
As you may have noticed there are only three commits since 10.3.3, which
imho are quite serious of people hitting those issues.
Thus I do plan on releasing 10.3.4 this Friday.
The usual summary with testing & stats will be out on Wednesday, as I
would like to see if we'll have any addi
On 14/11/14 14:14, Emil Velikov wrote:
> On 02/11/14 18:27, David Heidelberg wrote:
>> Hello everyone!
>>
>> First I'd like thank you for great feedback.
>> Sending third Gallium Nine merge request. We reduced number of commits
>> to necessary minimum. I hope all proposed changes are incorporated i
The issue with STORE isn't whether it's necessary (it is!), but the
exact semantics of the TGSI opcode. The way I have it in my patch
right now is that it doesn't have a destination, which upsets the dead
code removal logic in st_glsl_to_tgsi greatly. For now I've just
commented it out, but that's
Hi,
I agree with the solution. Considering "images" as "buffers" or "buffers"
as "images" (as they are operated inside shaders but not texture units)
makes sense. I think we can make atomic buffers as a part of
ARB_shader_image_load_store. Because, images are 2D array of buffers with
atomic operati
>
>
> Looking at u_atomic.h there is a section that uses
> PIPE_ATOMIC_ASM_MSVC_X86 and has explicit assembly, and there's a
> section that uses PIPE_ATOMIC_MSVC_INTRINSIC and has intrinsics. No
> clue whatsoever what the difference between them is, but presumably it
> doesn't exist solely for the
On Mon, Nov 17, 2014 at 2:15 PM, Patrick Baggett
wrote:
>
>
> On Mon, Nov 17, 2014 at 12:20 PM, Axel Davy wrote:
>>
>> From: Christoph Bumiller
>>
>> At this moment we use only zero or positive values.
>>
>> v2: Implement it for also for Solaris, MSVC assembly
>> and enable for other combina
On Mon, Nov 17, 2014 at 12:20 PM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> v3: Replace MSVC assembly by assert + warning during compila
On Mon, Nov 17, 2014 at 2:05 PM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> v3: Replace MSVC assembly by assert + warning during compilati
From: Christoph Bumiller
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly by assert + warning during compilation
v4: remove inc and dec with return for MSVC assembly
Signed
On Mon, Nov 17, 2014 at 1:20 PM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> v3: Replace MSVC assembly by assert + warning during compilati
From: Christoph Bumiller
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly by assert + warning during compilation
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/
Not sure if that's the right place, but this framebuffer state is set
by the driver and not a state tracker. Compute shader read-write
resources (buffers, images) are implemented by the CB block on r600
and are referred to as RAT (random access target) in the register
docs. The first 0-7 binding sl
2014-11-17 18:28 GMT+01:00 Thomas Helland :
> 2014-11-17 15:48 GMT+01:00 Bruno Jimenez :
>> On Mon, 2014-11-17 at 02:51 +0100, Thomas Helland wrote:
>>> The spec states that pow is undefined for x < 0.
>>> Just set the range to correspond to a constant 0
>>> if this is the case.
>>> ---
>>> src/gl
I'm not, in principle, opposed to merging st/nine into the tree. I've
reviewed all the patches that I'm qualified to review (which is the
vast minority of them -- 3 total), and I have outstanding feedback on
one of them (the atomic stuff).
I've asked Axel to provide a sample program which could be
Reviewed-by: Jakob Bornecrantz
On 17 Nov 2014 18:11, "Brian Paul" wrote:
> Fix oversights from the "add a window_space option to the passthrough
> vertex shader" patch.
> ---
> src/gallium/tests/trivial/quad-tex.c |2 +-
> src/gallium/tests/trivial/tri.c |2 +-
> 2 files changed, 2
Fix oversights from the "add a window_space option to the passthrough
vertex shader" patch.
---
src/gallium/tests/trivial/quad-tex.c |2 +-
src/gallium/tests/trivial/tri.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/tests/trivial/quad-tex.c
b/src
On Mon, 2014-11-17 at 16:01 +, Emil Velikov wrote:
> On 17/11/14 15:34, Ilia Mirkin wrote:
> > On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov
> > wrote:
> >> Hi Sedat,
> >>
> >> On 15/11/14 12:50, Sedat Dilek wrote:
> >>> Cosmetics? Intended?
> >>>
> >>> $ LC_ALL=C git status
> >>> # On branc
Am 17.11.2014 um 16:21 schrieb Jose Fonseca:
>
> On 17/11/14 13:32, Ilia Mirkin wrote:
>> Well, nvidia hw (pre-GM204; it seems like it's supported there now)
>> doesn't support setting gl_Layer from VS, so it's just not an option
>> there. However I do believe that the HW has enough support to han
On Mon, Nov 17, 2014 at 10:58 AM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxilia
Reviewed-by: Ilia Mirkin
On Mon, Nov 17, 2014 at 10:58 AM, Axel Davy wrote:
> From: Christoph Bumiller
>
> v2: moved in in same order as in p_shader_tokens (thanks Brian)
>
> Reviewed-by: Marek Olšák
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 1 +
Because shader resources were already specified as pipe_surfaces (in
the existing, albeit presently unused API). A pipe_surface is a
wrapper around a resource that specifies what "view" of the resource
should be writable, and attaches an optional format to that resource.
Normally pipe_surfaces are
Please split up this patch into:
1. gallium comment fixes
2. linker string fixes
3. hash table code changes
-Brian
On 11/17/2014 07:27 AM, Andres Gomez wrote:
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
segfault on linking as the binding hash
Hi,
I am having difficulty in understanding why you implemented pipe_surface in
st_atom_atomicbuf.c.
On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash
wrote:
> Hi,
>
> On Sunday, November 16, 2014, Ilia Mirkin wrote:
>
>> The direction I went in was by adapting the shader resources interface
>> f
From: Michael Varga
In a few locations handles were being added but not removed.
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/buffer.c | 1 +
src/gallium/state_trackers/va/context.c | 1 +
src/gallium/state_trackers/va/image.c | 1 +
3 files changed, 3 insertions(+)
diff
Sorry, patch 4 is too big the mailing list.
The entire serie can be found here:
https://github.com/iXit/Mesa-3D/commits/for-upstream-5
On 17/11/2014 16:58, Axel Davy wrote :
Hi,
Here is last (4th) iteration of Gallium Nine patches.
We have integrated the new feedback we have got and hope
the
From: Michael Varga
When calling vaCreateImage() an internal copy of VAImage is maintained
since the allocation of "image" may not be guaranteed to live long enough.
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/image.c | 70 +++---
src/gallium/sta
On 17/11/14 15:34, Ilia Mirkin wrote:
> On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov
> wrote:
>> Hi Sedat,
>>
>> On 15/11/14 12:50, Sedat Dilek wrote:
>>> Cosmetics? Intended?
>>>
>>> $ LC_ALL=C git status
>>> # On branch master
>>> # Your branch is up-to-date with 'origin/master'.
>>> #
>>> no
On Mon, Nov 17, 2014 at 11:01 AM, Emil Velikov wrote:
> On 17/11/14 15:34, Ilia Mirkin wrote:
>> On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov
>> wrote:
>>> Hi Sedat,
>>>
>>> On 15/11/14 12:50, Sedat Dilek wrote:
Cosmetics? Intended?
$ LC_ALL=C git status
# On branch master
From: Christoph Bumiller
Implement pipe_loader_sw_probe_wrapped which allows to use the wrapped
software renderer backend when using the pipe loader.
v2: - remove unneeded ifdef
- use GALLIUM_PIPE_LOADER_WINSYS_LIBS
- check for CALLOC_STRUCT
thanks to Emil Velikov
Signed-off-by: Dav
From: Christoph Bumiller
Signed-off-by: David Heidelberg
---
src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c
b/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c
index e552ac2
From: Christoph Bumiller
v2: moved in in same order as in p_shader_tokens (thanks Brian)
Reviewed-by: Marek Olšák
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
Implements vblank_mode and throttling, which allows us change default ratio
between framerate and input lag.
Signed-off-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/adapter9.h | 1 +
src/gallium/state_trackers/nine/swapchain9.c| 5
src/galli
Hi,
Here is last (4th) iteration of Gallium Nine patches.
We have integrated the new feedback we have got and hope
the status of the serie is good enough now for merge.
Thanks,
Axel Davy
Axel Davy (2):
nine: Add drirc options (v2)
nine: Implement threadpool
Christoph Bumiller (5):
tgsi
From: Christoph Bumiller
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/util/u_atomic.h | 78 +++
1 file c
DRI_PRIME setups have different issues due the lack of dma-buf fences
support in the drivers. For DRI3 DRI_PRIME, a race can appear, making
tearings visible, or worse showing older content than expected. Until
dma-buf fences are well supported (and by all drivers), an alternative
is to send the buf
From: Christoph Bumiller
v3: thanks to Brian, improved coding style, also glennk helped spot few
things (unsigned -> int, two constify)
v4: thanks Ilia improved function, dropped u_box_clip_3d
v5: incorporated rest of Gregor proposed changes,clean ups
v6: u_box_clip_2d simplify proposed by Ilia M
On 15/11/14 17:50, Marek Olšák wrote:
> I've always found the X.Org versioning scheme unintuitive. This is
> actually for the first time after ~5 years of contributing to open
> source graphics that I finally understand how the X versioning works.
> Granted, I had never been interested in it anyway
On 15/11/14 17:44, Ilia Mirkin wrote:
> On Sat, Nov 15, 2014 at 6:52 AM, Emil Velikov
> wrote:
>> On 14 November 2014 19:50, Ilia Mirkin wrote:
>>> On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov
>>> wrote:
Hello all,
This is an old question that I had laying around - why doesn't
From: Michael Varga
added BGRA format
create/destroy
set image
associate/deassociate
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/subpicture.c | 160 ++---
src/gallium/state_trackers/va/va_private.h | 12 +++
2 files changed, 159 insertions(+), 13 del
From: Michael Varga
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/surface.c | 120
1 file changed, 120 insertions(+)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index 0d0b863..8d4487b 100644
-
On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov wrote:
> Hi Sedat,
>
> On 15/11/14 12:50, Sedat Dilek wrote:
>> Cosmetics? Intended?
>>
>> $ LC_ALL=C git status
>> # On branch master
>> # Your branch is up-to-date with 'origin/master'.
>> #
>> nothing to commit, working directory clean
>>
>> $ LC_A
Hi Sedat,
On 15/11/14 12:50, Sedat Dilek wrote:
> Cosmetics? Intended?
>
> $ LC_ALL=C git status
> # On branch master
> # Your branch is up-to-date with 'origin/master'.
> #
> nothing to commit, working directory clean
>
> $ LC_ALL=C git checkout -b 10.4 origin/10.4
> Branch 10.4 set up to track
On 17/11/14 13:32, Ilia Mirkin wrote:
Well, nvidia hw (pre-GM204; it seems like it's supported there now)
doesn't support setting gl_Layer from VS, so it's just not an option
there. However I do believe that the HW has enough support to handle
color masking as well as scissors, so I might try to
On 17/11/14 14:44, Erik Faye-Lund wrote:
> On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
>> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
>>> wrote:
So when checking/building sse code we have three possibilities:
1 Old c
On Mon, Nov 17, 2014 at 3:50 PM, Ilia Mirkin wrote:
> On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund wrote:
>> On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
>>> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
wrote:
> So
On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund wrote:
> On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
>> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
>>> wrote:
So when checking/building sse code we have three possibilities
On Mon, 2014-11-17 at 02:51 +0100, Thomas Helland wrote:
> The spec states that pow is undefined for x < 0.
> Just set the range to correspond to a constant 0
> if this is the case.
> ---
> src/glsl/opt_minmax.cpp | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/src/glsl/opt_
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
>> wrote:
>>> So when checking/building sse code we have three possibilities:
>>> 1 Old compiler, throws an error when using -msse*
>>>
On Mon, Nov 17, 2014 at 1:45 AM, Michel Dänzer wrote:
> On 14.11.2014 19:37, Marek Olšák wrote:
>> surface_destroy should never be called directly, because surfaces have
>> a reference counter. For unreferencing resources, use
>> pipe_surface_reference(&pointer, NULL). It will call surface_destroy
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
segfault on linking as the binding hash tables are
not included in the shader program. Obviously, we
cannot make the linking stage succeed without the
bound attributes but we can prevent the crash and
jus
Well, nvidia hw (pre-GM204; it seems like it's supported there now)
doesn't support setting gl_Layer from VS, so it's just not an option
there. However I do believe that the HW has enough support to handle
color masking as well as scissors, so I might try to add a PIPE_CAP
which indicates that pipe
Thanks Emil, makes sense. I totally missed the stable tag.
Jose
From: Emil Velikov
Sent: 16 November 2014 21:12
To: Jose Fonseca; Tom Stellard
Cc: emil.l.veli...@gmail.com; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] llvmpipe: Avoid de
> I take that despite that it's still a good idea to keep around if/when one
> needs it.
Yep. I don't oppose moving it elsewhere (e.g, src/gallium/tools/) if its
presence in src/gallium/auxiliary/gallivm is confusing.
> Apologies for the breakage, it was definitely not intended to get someone
Hi Marek,
> First of all, sorry for breaking Draw yesterday.
No problem. draw_llvm.c was really obfuscating the fact that it relied on the
layout of the pipe_viewport_state.
> There's also the OpenGL extension AMD_vertex_shader_layer which is
> supported by all GS-capable Mesa drivers except fo
On Sun, Nov 16, 2014 at 01:37:52AM +, Emil Velikov wrote:
> On 13/11/14 18:05, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously
> > specified, which has the effect that some kernel drivers do not consider
> > the .p
82 matches
Mail list logo
