It's highly unlikely that there will be enough memory in the system to
allocate enough space for this, but we should still expose the hardware
limit. It's what the Intel Windows driver does, and it seems most other
vendors do likewise.
Cc: i...@freedesktop.org
Bugzilla: https://bugs.freedesktop.o
Even with the other limits raised, TestProxyTexImage would still reject
textures > 1GB in size. This is an artificial limit; nothing prevents
us from having a larger texture. I stayed shy of 2GB to avoid the
larger-than-aperture situation.
For 3D textures, this raises the effective limit:
- RGB
Gen4+ supports 8192x8192 cube maps. Ivybridge and later can actually
support 16384, but that would place GL_MAX_CUBE_MAP_TEXTURE_SIZE above
GL_MAX_TEXTURE_SIZE, which seems like a bad idea.
(Unfortunately, we can't bump GL_MAX_TEXTURE_SIZE to 16384 without
causing regressions due to awful W-tiled
https://bugs.freedesktop.org/show_bug.cgi?id=74312
--- Comment #2 from Fabio Pedretti ---
Mmh, this is not a very constructive answer. I know ilo is experimental and
inferior to i965 but since it's provided and buildable, I would have expected
it to install fine. Also, to be used, one needs anywa
https://bugs.freedesktop.org/show_bug.cgi?id=72877
Christian Zigotzky changed:
What|Removed |Added
CC||chzigot...@xenosoft.de
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=72877
Christian Zigotzky changed:
What|Removed |Added
Version|9.2 |10.0
--- Comment #8 from Christian
https://bugs.freedesktop.org/show_bug.cgi?id=72877
--- Comment #9 from Christian Zigotzky ---
The problem is the package libgl1-mesa-dri. I have installed the old package
libgl1-mesa-dri 8.0.5-4 with "Force Version" with the Synaptic package manager
and this has solved the problem with the wrong
On 02/01/2014 11:30 PM, Kenneth Graunke wrote:
ctx is always used, even on release builds.
Signed-off-by: Kenneth Graunke
For the series: Reviewed-by: Brian Paul
Nice clean-ups!
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
htt
This has been wrong for many years. It was originally 0x000F and long
ago there was discussion about whether GL_ALL_ATTRIB_BITS should include
the then-new GL_MULTISAMPLE_BIT bit. Eventually the ARB decided that
glPushAttrib(GL_ALL_ATTRIB_BITS) should save all current and future
attribute gro
On 01/30/2014 02:20 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/main/bufferobj.c | 98
> ++
> src/mesa/main/bufferobj.h | 4 ++
> src/mesa/main/extensions.c | 1 +
> src/mesa/main/mtypes.h | 2 +
> 4 files changed, 105 inser
On 01/30/2014 09:51 AM, Rogovin, Kevin wrote:
>> @@ -487,6 +486,7 @@ setup_shader_for_sampler(struct gl_context *ctx, struct
>> glsl_sampler
>> *sampler)
>> "void main()\n"
>> "{\n"
>> " gl_FragCo
On 01/13/2014 11:31 PM, Ian Romanick wrote:
> Fast forwarding 3 months from the 10.0 release (November 30th) is
> February 28th. I'd like to propose the following set of dates:
>
> January 31st: Feature freeze / 10.1 branch created. I promise to not
> let anyone on my team (myself included) dump
Is there a way to do the HDP flush at the bottom of the pipe? Can this
be fixed in the kernel?
For now, it would be safer to use GTT for all persistent mappings.
I'll update the patch.
Marek
On Sat, Feb 1, 2014 at 11:58 AM, Christian König
wrote:
> Am 31.01.2014 21:36, schrieb Alex Deucher:
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=74312
--- Comment #3 from Matt Turner ---
> 5816a471 (Chia-I Wu 2012-12-13 06:01:23 +0800 33) noinst_LTLIBRARIES
> = ilo_dri.la
This seems to be by design, and with my distributor hat on I'm not interested
in changing it.
--
You are receivi
Brian Paul writes:
> This has been wrong for many years. It was originally 0x000F and long
> ago there was discussion about whether GL_ALL_ATTRIB_BITS should include
> the then-new GL_MULTISAMPLE_BIT bit. Eventually the ARB decided that
> glPushAttrib(GL_ALL_ATTRIB_BITS) should save all cur
From: Marek Ols(ák http://lists.freedesktop.org/mailman/listinfo/mesa-dev>>
---
src/gallium/drivers/radeon/r600_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index f80a6a2..434a65
Well, it's kinda obvious what would happen. The buffer would be
relocated to VRAM.
Do you have any suggestion how to find out if the buffer should be in
GTT instead?
Marek
On Mon, Feb 3, 2014 at 12:13 AM, Axel Davy wrote:
>>From: Marek Olšák
>>
>>---
>> src/gallium/drivers/radeon/r600_texture.
On Sam, 2014-02-01 at 15:08 +0100, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/r600_texture.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_texture.c
> b/src/gallium/drivers/radeon/r600_texture.c
> index
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73781
Signed-off-by: Ahmed Allam
---
src/gallium/drivers/r600/r600_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index a0d527b..86908
On Don, 2014-01-30 at 10:43 -0500, Tom Stellard wrote:
> On Wed, Jan 29, 2014 at 06:23:00PM +0900, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > V_ADD_F32 with source modifier does not produce -0.0 for this. Just
> > manipulate the sign bit directly instead.
>
> That's strange, so does th
20 matches
Mail list logo
