bump
On Fri, Mar 25, 2011 at 8:34 AM, Morris Ford wrote:
> I am looking for assistance in getting a java jogl app set up to use the
> osmesa off-screen rendering. Does anyone have a simple example that they
> would be willing to share?
> Morris
>
___
m
On 26.03.2011 21:52, Denis Steckelmacher wrote:
> Hello,
>
> After some messages on this list, I reconsidered my GSoC proposal and decided
> to give a try at an OpenCL state tracker. I will base my work on the Clover
> branch of Mesa.
>
> I read its code, which is very well-done and clean, but I
Hello,
To be perfectly honest I'm not sure I know much about how OpenCL is supposed
to work, but I know that shaders are supposed to be doing math on vectors and
multidimensional matrices, so my guess would be you'd have to find a way to
translate OpenCL code into shader code, than compile and
Hello,
After some messages on this list, I reconsidered my GSoC proposal and decided
to give a try at an OpenCL state tracker. I will base my work on the Clover
branch of Mesa.
I read its code, which is very well-done and clean, but I saw one big
difficulty : I don't know how to translate LLVM
On Sat, Mar 26, 2011 at 1:01 PM, Matt Turner wrote:
> On Sat, Mar 26, 2011 at 4:53 PM, Alex Deucher wrote:
>> Plus, on AMD hardware at least, on
>> r1xx-r5xx asics we didn't have UVD so we used the 3D engine for video
>> decode and it worked well, even on mobile asics.
>
> I presume that r100 and
On Sat, Mar 26, 2011 at 4:53 PM, Alex Deucher wrote:
> Plus, on AMD hardware at least, on
> r1xx-r5xx asics we didn't have UVD so we used the 3D engine for video
> decode and it worked well, even on mobile asics.
I presume that r100 and r200 aren't capable of decoding WebM/H264, but
what about r3
On Fri, Mar 25, 2011 at 5:44 PM, Matt Turner wrote:
> On Wed, Mar 23, 2011 at 4:28 PM, ★ Emeric wrote:
>> Hi everyone,
>> My name is Emeric, I am a 22 years old french student, and I am
>> currently looking to apply to the google summer of code 2011.
>> I saw the "Gallium H.264 decoding" idea on
On Fri, Mar 25, 2011 at 5:54 AM, Liu, Xinyun wrote:
> Meet the same build issue. And fixed it with the same way.
Thanks. I had a fix from Benjamin sitting in my git repo that I
hadn't pushed yet. I just pushed that now.
Kristian
> diff --git a/src/egl/wayland/wayland-drm/Makefile
> b/src/egl/
The vertex color clamp control is a property of an API,
a lot like gl_rasterization_rules.
The state should be set according to the API being implemented, for example:
OpenGL Compatibility: enabled by default
OpenGL Core: disabled by default
D3D11: always disabled
This patch also changes
ARB_texture_float disables clamping of the texture border color,
ARB_color_buffer_float only modifies clamping of the glGet query.
---
src/mesa/main/texparam.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam
These two small patches are follow-ups to the ARB_color_buffer_float work. The
second patch removes PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL, because it's more of
an API property than a state.
On a side note, there are yet a few things that can be done:
- If anyone requires clamp_fragment_color to be
11 matches
Mail list logo
