https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 28837, which changed state.
Bug 28837 Summary: varying vec4 index support
https://bugs.freedesktop.org/show_bug.cgi?id=28837
What|Old Value |New Value
https://bugs.freedesktop.org/show_bug.cgi?id=29490
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 27914, which changed state.
Bug 27914 Summary: GLSL compiler uses MUL+ADD where it could use MAD
https://bugs.freedesktop.org/show_bug.cgi?id=27914
What|Old Value |New Value
-
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 27060, which changed state.
Bug 27060 Summary: [965] piglit glsl-fs-raytrace failure due to lack of
function calls.
https://bugs.freedesktop.org/show_bug.cgi?id=27060
What|Old Value |New
https://bugs.freedesktop.org/show_bug.cgi?id=29601
Summary: Crash in video games in the new glsl compiler
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Prio
(fix done)
I just looked at the asm output by glsl2. It seems that merging scalar
instructions into vector ones is still a good thing. I will start to work on it.
Cheers,
Ben
From: mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org
[mesa-de
- In one optimization pass, register files may have been messed therefore
merging instructions which use the same index in two different register files
- The fix consists in only processing temporary registers as it must be
---
src/mesa/program/prog_optimize.c |6 +-
1 files changed, 5
On Tue, 10 Aug 2010 22:11:22 +0400, randrianas...@gmail.com wrote:
> Hello all!
>
> Today i dived into GLSL for first time, so sorry if i write something stupid.
>
> One user at #radeon (nick ) asked why some shade doesn't work.
>
> Here is link to vertex shader as i saw it today:
>
> http:/
I am looking at the regression for this test
Ben
From: Ian Romanick [...@freedesktop.org]
Sent: Monday, August 16, 2010 8:17 PM
To: mesa-dev@lists.freedesktop.org; Segovia, Benjamin
Subject: Re: [Mesa-dev] Merge of glsl2 branch to master
-BEGIN PGP SIG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
> Ian Romanick wrote:
>> I propose that we merge master to glsl2 on *Friday, August 13th* (one
>> week from today). Barring unforeseen issues, I propose that we merge
>> glsl2 to master on *Monday, August 16th*.
>
> The master ->
On Mon, Aug 16, 2010 at 4:53 PM, Luca Barbieri wrote:
>> IIRC, the vertex fetch constants for r6xx+ accept 0 stride.
>
> But does the hardware fetch the same value repeatedly, wasting memory
> bandwidth, or is it smart enough to fetch it once and store it?
> (question applies to both r300-r500 and
> IIRC, the vertex fetch constants for r6xx+ accept 0 stride.
But does the hardware fetch the same value repeatedly, wasting memory
bandwidth, or is it smart enough to fetch it once and store it?
(question applies to both r300-r500 and r600-eg)
In other words, is it necessary to rewrite shaders a
Henri Verbeet writes:
> Should it ever be valid to destroy a bo that's still mapped in the
> first place though?
In 2.9.2:
If a buffer object is deleted while it is bound, all bindings to
that object in the current context (i.e. in the thread that called
DeleteBuffers) are reset to zero.
On Mon, Aug 16, 2010 at 12:01 PM, Luca Barbieri wrote:
>> It seems like there is an alternate fix possible -- modify the mesa
>> fixed-function vertex program generator to put these constant values in
>> the constant buffer, rather than passing them as vertex data. That
>> would remove the need f
On Mon, Aug 16, 2010 at 6:01 PM, Luca Barbieri wrote:
> > It seems like there is an alternate fix possible -- modify the mesa
> > fixed-function vertex program generator to put these constant values in
> > the constant buffer, rather than passing them as vertex data. That
> > would remove the nee
There may actually be something mapped in that range, especially for large
buffers like e.g. the GL Drawable. Should it ever be valid to destroy a bo
that's still mapped in the first place though?
---
src/gallium/winsys/r600/drm/radeon_bo.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion
On Mon, 2010-08-16 at 10:30 -0700, nobled wrote:
> I think this might be the problem that kept -disable-mmx from working;
> can somebody test it? (attached)
>
> @@ -152,15 +151,13 @@ lp_set_target_options(void)
> * See also:
> * - http://llvm.org/bugs/show_bug.cgi?id=3287
> * -
> -Original Message-
> From: Ian Romanick [mailto:i...@freedesktop.org]
> Sent: Monday, August 16, 2010 10:18 AM
> To: Vinson Lee
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: Mesa (glsl2): mesa: Check that _XOPEN_SOURCE is defined
> before using it.
>
> -BEGIN PGP SIGNED MESSAGE
I think this might be the problem that kept -disable-mmx from working;
can somebody test it? (attached)
@@ -152,15 +151,13 @@ lp_set_target_options(void)
* See also:
* - http://llvm.org/bugs/show_bug.cgi?id=3287
* -
http://l4.me.uk/post/2009/06/07/llvm-wrinkle-3-configuration-w
On Mon, Aug 16, 2010 at 7:04 PM, Niels Ole Salscheider <
niels_...@salscheider-online.de> wrote:
> Hello,
>
> when I try to run any OpenGL program like glxgears I get the following
> (radeon
> x700, gallium, mesa git):
> r300_state_derived.c:214:r300_rs_col_write: Assertion `type != WRITE_COLOR'
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vinson Lee wrote:
> Module: Mesa
> Branch: glsl2
> Commit: a0b0afc6944b00df27145a96ad2727a36752e1d6
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=a0b0afc6944b00df27145a96ad2727a36752e1d6
>
> Author: Vinson Lee
> Date: Sun Aug 15 13:
Hello,
when I try to run any OpenGL program like glxgears I get the following (radeon
x700, gallium, mesa git):
r300_state_derived.c:214:r300_rs_col_write: Assertion `type != WRITE_COLOR'
failed.
This assertion was added by Marek Olšák in commit
683ef52e19576f6e1263bc7d25fc9475c519eade.
Unfortun
> It seems like there is an alternate fix possible -- modify the mesa
> fixed-function vertex program generator to put these constant values in
> the constant buffer, rather than passing them as vertex data. That
> would remove the need for us to have this unique capability at the
> gallium level
> Thanks Luca, that looks good. debug_get_option_draw_use_llvm would probably be
> better served being called draw_get_option_use_llvm or such since it doesn't
> have that much to do with debug but that's just a nitpick.
Done.
The root of the problem though is that debug_get_option_* are
similarly
On Mon, Aug 16, 2010 at 10:54 AM, Luca Barbieri wrote:
> Regarding OpenCL, it was found that nv50 has the normalization bit in
> the sampler view, while r600 has it in the shader instruction.
>
> Thus, for nv50, the are two options:
> 1. Move the bit from the sampler state to the sampler view -> h
Regarding OpenCL, it was found that nv50 has the normalization bit in
the sampler view, while r600 has it in the shader instruction.
Thus, for nv50, the are two options:
1. Move the bit from the sampler state to the sampler view -> have the
OpenCL state tracker create two sampler views, one for ea
> To represent all possibilities you'd need two flags, one for normalized
> and one for unnormalized, such that OpenCL could set (NORMALIZED |
> UNNORMALIZED).
A small correction: I think we would actually need three flags:
- Normalized
- Unnormalized with other wrap modes
- Unnormalized with clam
On Monday 16 August 2010 09:59:56 Jakob Bornecrantz wrote:
> On 16 aug 2010, at 14.29, Keith Whitwell wrote:
> > To represent all possibilities you'd need two flags, one for
> > normalized
> > and one for unnormalized, such that OpenCL could set (NORMALIZED |
> > UNNORMALIZED).
> >
> > Would that
> Looking at it we have two users of unnormalized coords GL texture rect and
> OpenCL. From what I can tell it would require a lot more then just a
> normalization hint to support OpenCL properly. And as was stated even r600
> hardware will have some problem supporting unnormalized with different e
On Sunday 15 August 2010 01:47:50 Luca Barbieri wrote:
> Currently draw_llvm refuses to create itself on non-SSE2 CPUs due to
> an alleged LLVM bug.
>
> However, this is implemented improperly, because other parts of draw
> still attempt to access draw->llvm, resulting in segfaults.
>
> Instead,
> Is this a fair summary of the intentions of the change?
It's an excellent summary.
> In this model, the state tracker would query the driver explicitly to
> find out what normalization to use for internal rendering, and pass
> through the API constraints otherwise.
What do you mean exactly by "q
On 16 aug 2010, at 14.29, Keith Whitwell wrote:
On Mon, 2010-08-16 at 04:54 -0700, Luca Barbieri wrote:
I added the two patchsets I posted to the list to the two branches
named in the subject.
The version pushed contain slight changes over the ones sent to the
ML:
1. In translate, Win64 supp
On 14.08.2010 17:47, Marek Olšák wrote:
> If PIPE_CAP_DEPTHSTENCIL_CLEAR_SEPARATE is not advertised and there is
> a D24S8 texture bound and the mask is BUFFER_BIT_DEPTH|BUFFER_BIT_STENCIL,
> the state tracker always cleared the texture with a quad instead of using
> pipe_context::clear.
> @@ -543
Luca,
It seems like there is an alternate fix possible -- modify the mesa
fixed-function vertex program generator to put these constant values in
the constant buffer, rather than passing them as vertex data. That
would remove the need for us to have this unique capability at the
gallium level tha
On Sun, Aug 15, 2010 at 6:46 AM, keith whitwell
wrote:
> On Fri, Aug 13, 2010 at 5:25 PM, Chia-I Wu wrote:
>> On Fri, Aug 13, 2010 at 11:35 PM, Keith Whitwell wrote:
>>> On Fri, 2010-08-13 at 08:09 -0700, Chia-I Wu wrote:
On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell wrote:
> On Fr
On Mon, 2010-08-16 at 04:54 -0700, Luca Barbieri wrote:
> I added the two patchsets I posted to the list to the two branches
> named in the subject.
>
> The version pushed contain slight changes over the ones sent to the ML:
> 1. In translate, Win64 support has been further fixed to use the
> prop
On Sat, Aug 14, 2010 at 5:18 AM, nobled wrote:
> Chia-I Wu wrote:
>>> Fixes a fatal build error when compiling just OpenGL ES libraries, since
>>> FEATURE_EXT_framebuffer_blit is disabled then, so the BlitFramebuffer
>>> member doesn't exist.
>> Is this change enough to make dri_r300 function as
I added the two patchsets I posted to the list to the two branches
named in the subject.
The version pushed contain slight changes over the ones sent to the ML:
1. In translate, Win64 support has been further fixed to use the
proper macro (_WIN64) and properly preserve xmm registers
2. unnormalize
We can save a bunch of computations in the LLVM code for constant
elemens.
---
src/gallium/auxiliary/draw/draw_llvm.c | 54 +++
src/gallium/auxiliary/draw/draw_pt.c| 15 ---
src/gallium/auxiliary/draw/draw_pt_vcache.c |2 +-
3 files changed, 40 inse
Currently, we set up both vertex elements and buffers at the same
time, and thus can trivially specify constant frequency where stride
is 0.
This allows drivers to improve performance by taking advantage of the
hint in the vertex elements CSO.
---
src/mesa/state_tracker/st_draw.c |6
We can save a bunch of computations in the LLVM code for constant
elemens.
---
src/gallium/auxiliary/draw/draw_llvm.c | 54 +++
src/gallium/auxiliary/draw/draw_pt.c| 15 ---
src/gallium/auxiliary/draw/draw_pt_vcache.c |2 +-
3 files changed, 40 inse
All these places already zero-initialize the structure, so this is not
strictly necessary, but is consistent with the general coding style.
---
src/gallium/auxiliary/util/u_blit.c |1 +
src/gallium/auxiliary/util/u_blitter.c |1 +
src/gallium/auxiliary/util/u_gen_mipma
I recently posted a patch that would set instance_divisor to 0x for
constant elements, so that the driver could take that knowledge into account
when creating the vertex elements CSO.
However, in Direct3D 11, the instance id system value is specified as a 32-bit
unsigned integers, which ca
Currently constant elements are specified only with a stride 0, while
per-instanced are implicitly indentified by a non-zero instance_divisor.
However, drivers often need to know whether an element is constant
or not when setting up the vertex element CSO instead of when setting
the buffers.
So,
I think this is fine. It's been a very long time since we had to worry
about this.
Keith
On Mon, 2010-08-16 at 01:17 -0700, Vinson Lee wrote:
> I am proposing to remove the check_os_katmai_support function from
> u_cpu_detect.
>
> util: Remove check_os_katmai_support.
>
> check_os_katmai_supp
I am proposing to remove the check_os_katmai_support function from u_cpu_detect.
util: Remove check_os_katmai_support.
check_os_katmai_support checks that the operating system running on a
SSE-capable processor supports SSE. This is necessary for unpatched 2.2.x and
earlier kernels. 2.4.x and l
46 matches
Mail list logo
