https://bugs.freedesktop.org/show_bug.cgi?id=27612
Summary: Mesa 7.8.1 does not compile against libdrm 2.4.20
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severity: normal
P
On nv30/nv40 support for patching fragment programs is already
necessary (constants must be patched in as immediates), and this can
be handled by just patching the end of the fragment program to include
a variable number of instructions to copy a temp to COLOR[x].
It's possible that there could be
>
> (3) Should gl_FragColor be aliased to gl_FragData[0]?
>
> RESOLUTION: No. A shader should write either gl_FragColor, or
> gl_FragData[n], but not both.
>
> Writing to gl_FragColor will write to all draw buffers specified
> with DrawBuffersARB.
>
> So I was really just maski
hello all,
thank you for reply
Actually I am working on arm board which support OpenGLES 1.1 and OpenGLES
2.0.
which provides hardware acceleration for redering images.
What my objective is that I want to implement this OpenGLES 2.0 into mesa
for interactive graphics with hardware acceleration to
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
> Dave Airlie wrote:
>>
>> Just going down the r300g piglit failures and noticed fbo-drawbuffers
>> failed, I've no idea
>> if this passes on Intel hw, but it appears the texenvprogram really
>> needs to understand the
>> draw buffers. The attached
Hi,
I've been looking into the GLES1/2 support in mesa and trying to
figure out how to make it work for DRI drivers as well. The current
approach only works for gallium, and it works by compiling mesa core
as different state trackers. Each state tracker is just a thin filter
on top of the public
https://bugs.freedesktop.org/show_bug.cgi?id=27586
Alex Deucher changed:
What|Removed |Added
Component|Drivers/DRI/R600|Mesa core
AssignedTo|dri-de...@li
