Re: [Mesa-dev] [Mesa-stable] [PATCH] glsl: fix several use-after-free bugs

I think get_variable_being_redeclared() deleting its argument in one specific case (sizing an unsized array via redeclaration) is really nasty and we should get rid of it, but this does fix the fallout: Reviewed-by: Chris Forbes On Sat, Oct 18, 2014 at 8:37 AM, Brian Paul wrote: > The get_varia

[Mesa-dev] [Bug 84570] Borderlands 2/Pre-Sequel: Constant frame rate drops while playing; really bad with additionl lighting

https://bugs.freedesktop.org/show_bug.cgi?id=84570 --- Comment #24 from Kai --- I've made some screenshots with the Pre-Sequel as well: . As you can see, big FPS drops coincide usually with buffer wait time and/or draw call spikes. Some of these spikes can be correlated

Re: [Mesa-dev] clEnqueueNDRangeKerne return error -52 with off-line compiled kernel

On Fri, Oct 17, 2014 at 05:34:40PM +0200, Vincent DEDIEU wrote: > Hi > > > > I compiled the very last mesa package (V10.4.0-devel) on Ubuntu-14.04 with > AMD RADEON. > > > > On a test program when I used clCreateProgramWithSource() and > clBuildProgram(), my kernel works perfectly. > > >

[Mesa-dev] [PATCH] glsl: fix several use-after-free bugs

The get_variable_being_redeclared() function can free the 'var' argument. Thereafter, we cannot assume that 'var' is a valid pointer. This patch replaces 'var->name' with 'earlier->name' in two places and calls is_gl_identifier(var->name) before 'var' might get freed. This fixes several piglit G

[Mesa-dev] clEnqueueNDRangeKerne return error -52 with off-line compiled kernel

Hi I compiled the very last mesa package (V10.4.0-devel) on Ubuntu-14.04 with AMD RADEON. On a test program when I used clCreateProgramWithSource() and clBuildProgram(), my kernel works perfectly. But when I tried to use an already compiled kernel with clCreateProgramWithBinary(), I get

[Mesa-dev] [SOC Ideas] Find common patterns in real GLSL shaders

Hi, I found the idea-page recently and am interested in tackling the problem labelled "Find common patterns in real GLSL shaders". Can anyone point me to any previous work attempted on this if any? I am interested in this because I like compilers and OpenGL. And while I have have some practical ex

Re: [Mesa-dev] --enable-glx-tls not working?

Thanks for the replies! And sorry for the inaccurate title. 2014-10-18 2:21 GMT+08:00 Matt Turner : > On Fri, Oct 17, 2014 at 9:18 AM, Boxiang Sun wrote: > > Hi, > > > > I build mesa with --enable-glx-tls option. But when use > > nm libGL.so.1.2.0 | grep glapi > > > > it still show these: > >

[Mesa-dev] [Bug 84570] Borderlands 2/Pre-Sequel: Constant frame rate drops while playing; really bad with additionl lighting

https://bugs.freedesktop.org/show_bug.cgi?id=84570 Kai changed: What|Removed |Added Summary|Borderlands 2: Constant |Borderlands 2/Pre-Sequel: |frame

Re: [Mesa-dev] --enable-glx-tls not working?

On Fri, Oct 17, 2014 at 9:18 AM, Boxiang Sun wrote: > Hi, > > I build mesa with --enable-glx-tls option. But when use > nm libGL.so.1.2.0 | grep glapi > > it still show these: > U _glapi_get_dispatch_table_size > U _glapi_get_proc_address > U _gla

[Mesa-dev] [Bug 84566] Unify the format conversion code

https://bugs.freedesktop.org/show_bug.cgi?id=84566 --- Comment #30 from Jason Ekstrand --- (In reply to Iago Toral from comment #29) > (In reply to Jason Ekstrand from comment #26) > > (In reply to Iago Toral from comment #24) > > > Jason, what do you think we should do for GL_COLOR_INDEX + GL_BI

Re: [Mesa-dev] --enable-glx-tls not working?

On 17/10/14 17:18, Boxiang Sun wrote: > Hi, > > I build mesa with --enable-glx-tls option. But when use > nm libGL.so.1.2.0 | grep glapi > > it still show these: > U _glapi_get_dispatch_table_size > U _glapi_get_proc_address > U _glapi_get_proc_o

[Mesa-dev] --enable-glx-tls not working?

Hi, I build mesa with --enable-glx-tls option. But when use nm libGL.so.1.2.0 | grep glapi it still show these: U _glapi_get_dispatch_table_size U _glapi_get_proc_address U _glapi_get_proc_offset U _glapi_set_context

[Mesa-dev] [PATCH v2] intel: Don't flush the old context in intelMakeCurrent

I wrote: > I guess I should try to explore intelMakeCurrent in a bit more > detail to try to determine whether it's ok not to flush. It looks like all the code between the flush and the call to _mesa_make_current it just operating on the new context not the old context and it looks fairly trivial

[Mesa-dev] [Bug 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting

https://bugs.freedesktop.org/show_bug.cgi?id=84570 Reuben changed: What|Removed |Added CC||reube...@yahoo.com -- You are receiving this m

Re: [Mesa-dev] [PATCH 07/10] radeonsi: clarify shader constant load functions

On 17.10.2014 00:34, Marek Olšák wrote: From: Marek Olšák I'll need indexed loads without the meta data flag for tessellation later. Also rename load_const to buffer_load_const to distinguish it from indexed const loads. [...] +static LLVMValueRef build_indexed_load(struct si_shader_context