Can we make this approximation conditional on an image-quality control
in driconf [or somewhere else]?
On Thu, Sep 12, 2013 at 5:00 PM, Chia-I Wu olva...@gmail.com wrote:
From: Chia-I Wu o...@lunarg.com
Replicate the gradient of the top-left pixel to the other three pixels in the
subspan, as
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 application using these drivers with a bunch of
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:
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 the
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 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
On Thu, Sep 12, 2013 at 2:06 PM, Chris Forbes chr...@ijw.co.nz 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 olva...@gmail.com wrote:
From:
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
On Thu, Sep 12, 2013 at 5:27 PM, Chris Forbes chr...@ijw.co.nz 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
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
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
johannesoberm...@gmx.de wrote:
I see current situation is better:
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
master:
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 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 attached my next
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 the dst
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 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.
-
Am 12.09.2013 18:47, schrieb Ian Romanick:
From: Ian Romanick ian.d.roman...@intel.com
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
On Thu, Aug 15, 2013 at 7:04 PM, Emil Velikov emil.l.veli...@gmail.comwrote:
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
On Thu, Sep 12, 2013 at 9:47 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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
On Thu, Aug 15, 2013 at 7:38 AM, Chia-I Wu olva...@gmail.com wrote:
On Thu, Aug 15, 2013 at 1:26 PM, Chia-I Wu olva...@gmail.com wrote:
On Sat, Aug 10, 2013 at 2:56 AM, Marek Olšák mar...@gmail.com wrote:
Most importantly, this hides all LLVM symbols. They shouldn't clash
with a different
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)
https://bugs.freedesktop.org/show_bug.cgi?id=69285
--- Comment #1 from Charles Huber genpfa...@gmail.com ---
Created attachment 85736
-- https://bugs.freedesktop.org/attachment.cgi?id=85736action=edit
Output with --disable-gallium-llvm
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=69285
--- Comment #2 from Charles Huber genpfa...@gmail.com ---
Created attachment 85737
-- https://bugs.freedesktop.org/attachment.cgi?id=85737action=edit
Output with --enable-gallium-llvm
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=69285
Charles Huber genpfa...@gmail.com changed:
What|Removed |Added
Summary|LLVM rendering bug |Enabling LLVM results
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
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
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 libraries where
On 09/12/2013 12:01 PM, Roland Scheidegger wrote:
Am 12.09.2013 18:47, schrieb Ian Romanick:
From: Ian Romanick ian.d.roman...@intel.com
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
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
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
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 updated
Hi Brian,
On Fri, Sep 13, 2013 at 8:46 AM, Brian Paul bri...@vmware.com 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
Sounds good to me.
On Fri, Sep 13, 2013 at 3:11 PM, Chia-I Wu olva...@gmail.com wrote:
On Thu, Sep 12, 2013 at 10:48 PM, Ian Romanick i...@freedesktop.org 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
From: Chia-I Wu o...@lunarg.com
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
36 matches
Mail list logo
