From: Chia-I Wu
Consider only the top-left and top-right pixels to approximate DDX in a 2x2
subspan, unless the application or the user requests a more accurate
approximation. This results in a less accurate approximation. However, it
improves the performance of Xonotic with Ultra settings by 2
Sounds good to me.
On Fri, Sep 13, 2013 at 3:11 PM, Chia-I Wu wrote:
> On Thu, Sep 12, 2013 at 10:48 PM, Ian Romanick wrote:
>> On 09/12/2013 01:06 AM, Chris Forbes wrote:
>>> Can we make this approximation conditional on an image-quality control
>>> in driconf [or somewhere else]?
>>
>> There's
On Thu, Sep 12, 2013 at 10:48 PM, Ian Romanick wrote:
> On 09/12/2013 01:06 AM, Chris Forbes wrote:
>> Can we make this approximation conditional on an image-quality control
>> in driconf [or somewhere else]?
>
> There's already a control that applications can use:
> GL_FRAGMENT_SHADER_DERIVATIVE_
Hi Brian,
On Fri, Sep 13, 2013 at 8:46 AM, Brian Paul wrote:
>
> I just pushed a gallium-bind-sampler-states branch to my git repo at
> git://people.freedesktop.org/~brianp/mesa
>
> It replaces the four
> pipe_context::bind_fragment/vertex/geometry/compute_sampler_states()
> functions with a sing
Am 13.09.2013 01:09, schrieb Ilia Mirkin:
> Hello,
>
> I sent a patch earlier to add a new PIPE_CAP about disallowing mixed
> fb cbuf/zsbuf sizes, which would be used to disable ARB_fbo. I think
> people were generally in favor, but I didn't see any actual
> Reviewed-By's, I'll resend it with upda
I just pushed a gallium-bind-sampler-states branch to my git repo at
git://people.freedesktop.org/~brianp/mesa
It replaces the four
pipe_context::bind_fragment/vertex/geometry/compute_sampler_states()
functions with a single bind_sampler_states() function:
void (*bind_sampler_states)(stru
Hello,
I sent a patch earlier to add a new PIPE_CAP about disallowing mixed
fb cbuf/zsbuf sizes, which would be used to disable ARB_fbo. I think
people were generally in favor, but I didn't see any actual
Reviewed-By's, I'll resend it with updated nouveau directories (I
guess everything got moved
On 09/12/2013 12:01 PM, Roland Scheidegger wrote:
> Am 12.09.2013 18:47, schrieb Ian Romanick:
>> From: Ian Romanick
>>
>> Everyone at the Khronos meeting was as surprised that GLSL didn't
>> already support this as we were. Several vendors said they'd ship it,
>> but there didn't seem to be enou
On 09/12/2013 02:44 AM, Kenneth Graunke wrote:
> On 09/11/2013 11:41 PM, Christian König wrote:
>> I completely agree.
>>
>> Building everything shared might speed up the build process a little bit
>> and save some space, but for the cost of having to handle allot of
>> rather small shared librarie
On 09/12/2013 11:29 AM, Paul Berry wrote:
> These functions are defined in EXT_texture_array, which makes no
> mention of what shader types they should be allowed in. At the time
> EXT_texture_array was introduced, functions ending in "Lod" were
> available only in vertex shaders, however this res
These functions are defined in EXT_texture_array, which makes no
mention of what shader types they should be allowed in. At the time
EXT_texture_array was introduced, functions ending in "Lod" were
available only in vertex shaders, however this restriction was lifted
in later spec versions and ext
https://bugs.freedesktop.org/show_bug.cgi?id=69285
Charles Huber changed:
What|Removed |Added
Summary|LLVM rendering bug |Enabling LLVM results in
https://bugs.freedesktop.org/show_bug.cgi?id=69285
--- Comment #2 from Charles Huber ---
Created attachment 85737
--> https://bugs.freedesktop.org/attachment.cgi?id=85737&action=edit
Output with --enable-gallium-llvm
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69285
--- Comment #1 from Charles Huber ---
Created attachment 85736
--> https://bugs.freedesktop.org/attachment.cgi?id=85736&action=edit
Output with --disable-gallium-llvm
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69285
Priority: medium
Bug ID: 69285
Assignee: mesa-dev@lists.freedesktop.org
Summary: LLVM rendering bug
Severity: normal
Classification: Unclassified
OS: Linux (All)
Re
On Thu, Aug 15, 2013 at 7:38 AM, Chia-I Wu wrote:
> On Thu, Aug 15, 2013 at 1:26 PM, Chia-I Wu wrote:
> > On Sat, Aug 10, 2013 at 2:56 AM, Marek Olšák wrote:
> >> Most importantly, this hides all LLVM symbols. They shouldn't clash
> >> with a different LLVM version used by apps (at least in the
From: Ian Romanick
Everyone at the Khronos meeting was as surprised that GLSL didn't
already support this as we were. Several vendors said they'd ship it,
but there didn't seem to be enough interest to put in the effort to make
it ARB or KHR.
Signed-off-by: Ian Romanick
Cc: Matt Turner
---
d
On Thu, Sep 12, 2013 at 9:47 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Everyone at the Khronos meeting was as surprised that GLSL didn't
> already support this as we were. Several vendors said they'd ship it,
> but there didn't seem to be enough interest to put in the effort to make
> it
On Thu, Aug 15, 2013 at 7:04 PM, Emil Velikov wrote:
> Hello list
>
> Feeling inspired by the automake work done in mesa, I felt like
> finishing a few things that did not receive too much attention
> * use Makefile.sources wherever possible
> * cleanup the duplicated C{,PP,XX}FLAGS and factor o
Am 12.09.2013 18:47, schrieb Ian Romanick:
> From: Ian Romanick
>
> Everyone at the Khronos meeting was as surprised that GLSL didn't
> already support this as we were. Several vendors said they'd ship it,
> but there didn't seem to be enough interest to put in the effort to make
> it ARB or KHR
On 09/12/2013 02:08 AM, Kenneth Graunke wrote:
> For each sampler type, this tests that:
> - The base type is GLSL_TYPE_SAMPLER.
> - The dimensionality is set correctly.
> - The returned data type is correct.
> - The sampler_array and sampler_shadow flags are set correctly.
> - sampler_coordinate_c
On 09/12/2013 01:06 AM, Chris Forbes wrote:
> Can we make this approximation conditional on an image-quality control
> in driconf [or somewhere else]?
There's already a control that applications can use:
GL_FRAGMENT_SHADER_DERIVATIVE_HINT. I don't know whether or not /any/
app has ever used it.
On 12.09.2013 16:14, Roland Scheidegger wrote:
> Am 12.09.2013 03:40, schrieb Dave Airlie:
>>> Maybe the type isn't set correctly? Looks to me like these instructions
>>> end up in mkCmp, which will set both src and dst type but ignore src
>>> type and set both according to the same type (which was
Am 12.09.2013 03:40, schrieb Dave Airlie:
>>
>> Maybe the type isn't set correctly? Looks to me like these instructions
>> end up in mkCmp, which will set both src and dst type but ignore src
>> type and set both according to the same type (which was the dst type).
>>
>> Roland
>
> Okay I've attac
Am 12.09.2013 14:52, schrieb Marek Olšák:
I think current Gallium drivers only need one exported symbol to work:
__driDriverExtensions. See:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html
Yes that's indeed the right way of doing it, feel free to make the
changes Chia-l
Am Donnerstag, 12. September 2013, 14:52:15 schrieb Marek Olšák:
> I think current Gallium drivers only need one exported symbol to work:
> __driDriverExtensions. See:
> http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html
>
> Marek
readelf -s usr/lib64/dri/radeonsi_dri.so
mas
I think current Gallium drivers only need one exported symbol to work:
__driDriverExtensions. See:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html
Marek
On Thu, Sep 12, 2013 at 2:41 PM, Johannes Obermayr
wrote:
> I see current situation is better:
>
> Symbol table '.dynsym
I see current situation is better:
Symbol table '.dynsym' contains ...
master:
libdricore: 3675
i965_dri:398
after [PATCH 10/21]:
classic drivers:
libmesacore: 839
libmesadri: 348
total: 1187
i965_dri:397
gallium drivers:
libgallium: 833
libmesacore
On Thu, Sep 12, 2013 at 5:27 PM, Chris Forbes wrote:
> I guess fast-by-default. I imagine that more apps care about
> performance than care about the granularity of their derivatives.
That is my preference too. My concern is that the performance gain is
only observed on Haswell so far. Why is th
I guess fast-by-default. I imagine that more apps care about
performance than care about the granularity of their derivatives.
After a bit more thought -- In HLSL shader model 5 there's both
ddx_coarse() and ddx_fine() which gives the shader author the choice
between roughly these options. In a *v
On Thu, Sep 12, 2013 at 2:06 PM, Chris Forbes wrote:
> Can we make this approximation conditional on an image-quality control
> in driconf [or somewhere else]?
Sure. What would be the default behavior?
> On Thu, Sep 12, 2013 at 5:00 PM, Chia-I Wu wrote:
>> From: Chia-I Wu
>>
>> Replicate the g
Hi Armin,
Thank you very much ! My patch lacked the "configure_callback" part. I can
now use EGLUT with no trouble.
BTW, it would be nice to merge this upstream, as using git still fetches the
deprecated code now.
Regards,
Tarnyko
Armin K. writes:
On 09/11/2013 10:46 AM, Tarnyko wro
On 09/11/2013 11:41 PM, Christian König wrote:
> I completely agree.
>
> Building everything shared might speed up the build process a little bit
> and save some space, but for the cost of having to handle allot of
> rather small shared libraries where which each clashing the symbol space
> of any
Hi,
On Thursday, September 12, 2013 08:41:10 Christian König wrote:
> I completely agree.
>
> Building everything shared might speed up the build process a little bit
> and save some space, but for the cost of having to handle allot of
> rather small shared libraries where which each clashing th
For each sampler type, this tests that:
- The base type is GLSL_TYPE_SAMPLER.
- The dimensionality is set correctly.
- The returned data type is correct.
- The sampler_array and sampler_shadow flags are set correctly.
- sampler_coordinate_components() returns the correct value.
Signed-off-by: Kenn
35 matches
Mail list logo
