https://bugs.freedesktop.org/show_bug.cgi?id=31568
--- Comment #5 from Chia-I Wu 2010-11-19 23:53:31 PST ---
Created an attachment (id=40430)
View: https://bugs.freedesktop.org/attachment.cgi?id=40430
Review: https://bugs.freedesktop.org/review?bug=31568&attachment=40430
define IN_DRI_DRIVER
https://bugs.freedesktop.org/show_bug.cgi?id=31568
--- Comment #4 from Chia-I Wu 2010-11-19 23:33:27 PST ---
What is your setup? It seems your libGL.so and the DRI driver use different
versions of glapi, and IN_DRI_DRIVER is not defined when building the DRI
driver.
--
Configure bugmail: https
https://bugs.freedesktop.org/show_bug.cgi?id=31569
--- Comment #3 from Vinson Lee 2010-11-19 18:22:11 PST ---
mesa: a172368ef1500fd2c7c1e55133e8e098b73d97a5 (master)
A clean build still reproduces the crash.
I am building a debug r300g with scons.
$ scons
$ LIBGL_DRIVERS_PATH=build/linux-x86-d
https://bugs.freedesktop.org/show_bug.cgi?id=31568
--- Comment #3 from Vinson Lee 2010-11-19 18:19:41 PST ---
mesa: a172368ef1500fd2c7c1e55133e8e098b73d97a5 (master)
I retested with a clean build and it still crashing with the identical
backtrace.
--
Configure bugmail: https://bugs.freedesktop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2010 07:12 AM, Török Edwin wrote:
> Well in this case it is 512x128x16, so 4MB only. Maybe the limit should
> be on total texture size, not on one dimension only.
> Will the GL spec allow you to do that? i.e. claim you support N
> for width b
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_reg.h |5 -
src/gallium/drivers/i915/i915_state_sampler.c |3 +--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_reg.h
b/src/gallium/drivers/i915/i915_reg.h
index 24
This is needed to properly implement tiling flags. And the gem
implementation of buffer_from_handle already calls get_tiling, so
it's for free.
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_resource_texture.c |5 +++--
src/gallium/drivers/i915/i915_winsys.h |3
Also change the vbo reloc to unfenced - tiled vbos are not a great idea ;-)
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_context.h|3 +--
src/gallium/drivers/i915/i915_reg.h|2 ++
src/gallium/drivers/i915/i915_state_emit.c | 12 +---
3 files change
Wire up a fenced parameter, switch all relocations to _FENCED
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_batch.h |5 ++-
src/gallium/drivers/i915/i915_batchbuffer.h|4 +-
src/gallium/drivers/i915/i915_blit.c |6 ++--
src/gallium/
This way relaxed fencing is handled by libdrm. And buffers _can't_
ever change their tiling.
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_resource_texture.c | 16 ++--
src/gallium/drivers/i915/i915_winsys.h |9 -
src/gallium/winsys/i915/drm/i
type was only used to name the buffer. If needed, better let the
caller specify a meaningful name.
alignment is also rather unecessary. The kernel gem ignores it totally,
and we can't run on the old userspace fake bo manager due to lack of
dri2.
Signed-off-by: Daniel Vetter
---
src/gallium/driv
Different kernels have different restrictions for tiled buffers.
Hence use the libdrm abstraction to calculate the necessary
stride and height alignment requirements.
Not yet used.
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_winsys.h|8 +
src/gallium/winsys/i9
The drm winsys only ever handles one gem memory manager. Rip out
the unnecessary complication.
---
src/gallium/winsys/i915/drm/i915_drm_batchbuffer.c |2 +-
src/gallium/winsys/i915/drm/i915_drm_buffer.c |9 ++---
src/gallium/winsys/i915/drm/i915_drm_winsys.c |6 +++---
sr
Hi all,
This is my first stab at creating havoc in i915g. This cleans up a few
obsoletes things and implements execbuf2 support. This way the kernel isn't
forced to allocate a fence anymore if it's not needed. [Note: fence = the
intel hw thingy needed for tiling, not a gallium execution fence].
i
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_reg.h|2 ++
src/gallium/drivers/i915/i915_screen.c |8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_reg.h
b/src/gallium/drivers/i915/i915_reg.h
index 04620fe..cc28
Not using the gtt is considered harmful for performance. And for
partial uploads there's always drm_intel_bo_subdata.
Signed-off-by: Daniel Vetter
---
src/gallium/winsys/i915/drm/i915_drm_buffer.c | 16 ++--
src/gallium/winsys/i915/drm/i915_drm_winsys.h |1 -
2 files changed, 2
More in line with other intel drivers.
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_resource.h |4 ++--
src/gallium/drivers/i915/i915_resource_texture.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_res
It looks like this was meant to facilitate unfenced access to textures/
color/renderbuffers. It's totally incomplete and fundamentally broken
on a few levels:
- broken: The kernel needs to about every tiled bo to fix up bit17
swizzling on swap-in.
- unflexible: fenced/unfenced relocs from execbuf
It's intel, so always little endian!
Signed-off-by: Daniel Vetter
---
src/gallium/drivers/i915/i915_screen.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_screen.c
b/src/gallium/drivers/i915/i915_screen.c
index 3f0b7ae..0718325 100644
https://bugs.freedesktop.org/show_bug.cgi?id=31256
jonathan changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://bugs.freedesktop.org/show_bug.cgi?id=31256
--- Comment #3 from jonathan 2010-11-19 14:10:54 PST
---
Created an attachment (id=40421)
--> (https://bugs.freedesktop.org/attachment.cgi?id=40421)
The right patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
21 matches
Mail list logo
