On Thursday, June 04, 2015 07:04:51 PM Francisco Jerez wrote:
> See "i965/fs: Introduce FS IR builder." for the rationale.
>
> v2: Drop scalarizing VEC4 builder.
> v3: Take a backend_shader as constructor argument. Improve handling
> of debug annotations and execution control flags.
> ---
>
On Thursday, June 04, 2015 07:04:49 PM Francisco Jerez wrote:
> This series migrates the FS compiler back-end to the i965 IR builder I
> proposed a while ago as part of my ARB_shader_image_load_store series,
> and fixes a couple of bugs I found during the process. It doesn't yet
> attempt to conve
https://bugs.freedesktop.org/show_bug.cgi?id=89819
--- Comment #4 from Luke ---
> I did see a crash though when loading that page but it didn't seem related
Roland,
I just retested and only google-chrome is giving the results above. Firefox is
crashing like you reported. To test with chrome:
chr
https://bugs.freedesktop.org/show_bug.cgi?id=89018
--- Comment #18 from Sami Liedes ---
I'm not seeing this anymore on mesa/llvm git from today either on Radeon R9 270
or swrast.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
__
Please move the inline functions to a .c file.
Also, if they are not used by drivers/radeon or radeonsi, they
shouldn't be in drivers/radeon.
Marek
On Sat, Jun 6, 2015 at 10:33 PM, Jan Vesely wrote:
> v2: drop inline keyword
> drop radeon_llvm_dispose_kernel_module wrapper
>
> Signed-off-by
v2: drop inline keyword
drop radeon_llvm_dispose_kernel_module wrapper
Signed-off-by: Jan Vesely
---
I decided to keep radeon_shader_binary_clean,a nd dropped the other one.
src/gallium/drivers/r600/evergreen_compute.c | 24 +---
src/gallium/drivers/r600/r600_llvm.c
These are helpers that only exist in this one file. No reason to put them
in the visitor.
---
src/mesa/drivers/dri/i965/brw_fs.h| 4
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 25 ---
2 files changed, 13 insertions(+), 16 deletions(-)
diff --git
Previously, we just put the message for the EOT send as high in the file as
it would go. This is because the register pre-filling hardware will stop
all over the early registers in the file in preparation for the next thread
while you're still sending the last message. However, if something happe
https://bugs.freedesktop.org/show_bug.cgi?id=89819
--- Comment #3 from Luke ---
Roland,
Thanks for looking into this! If you need the tests in a piglit form, see:
Bug 89754 ->
http://cgit.freedesktop.org/piglit/commit/?id=aa97ac98dd8f1eab8f288f9509fdf3f91ffbecd6
and
Bug 89759 ->
http://cgit.f
Giuseppe Bilotta writes:
> On Fri, Jun 5, 2015 at 10:35 PM, Francisco Jerez
> wrote:
>>> OTOH, at least in OpenCL, this cap wouldn't be used 'raw' as
>>> performance hint, since the actual value returned (the
>>> PREFERRED_WORK_GROUP_SIZE_MULTIPLE) is a kernel property rather than a
>>> device
On Sat, Jun 06, 2015 at 12:58:05PM +0300, Alexander Monakov wrote:
> On Fri, Jun 5, 2015 at 5:14 PM, Chris Wilson wrote:
> > The blitter already has code to accommodate filling in the alpha channel
> > for BGRX destination formats, so expand this to also allow filling the
> > alpha channgel in RGB
On Fri, Jun 5, 2015 at 5:14 PM, Chris Wilson wrote:
> The blitter already has code to accommodate filling in the alpha channel
> for BGRX destination formats, so expand this to also allow filling the
> alpha channgel in RGBX formats.
>
> More importantly for the next patch is moving the test into
On 06/06/15 02:30, Tom Stellard wrote:
The only use of lp_profile() is wrapped in #if defined(PROFILE),
so there is no reason to build it unless this macro is defined.
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gal
On Jun 6, 2015 9:51 AM, "Eirik Byrkjeflot Anonsen"
wrote:
>
> Ilia Mirkin writes:
>
> > Sure. Fix it in GCC :) disable the bogus warning, whatever. I really
really
> > hate pandering to broken tools, sending the message that it's ok for the
> > tools to be broken.
>
> While I largely agree with t
14 matches
Mail list logo
