Am Tuesday 22 September 2009 23:25:09 schrieb Pauli Nieminen:
Too bad GPU reset is already now stopping this use case while it doesn't
protect user from possible attack causing multiple GPU reset in row. So
this long rendering operation blocking GPU is more like scheduler or mesa
bug that it
Am Tuesday 22 September 2009 21:13:47 schrieb Pauli Nieminen:
Hi!
I have been thinking GPU reset as possible DoS attack from
user-space.Problem here is that display doesn't work anymore at all if
attacker chooses to run a application that constantly causes GPU hang. It
would be of course
=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Nicolai Hähnle nhaeh...@gmail.com
---
src/mesa/state_tracker/st_cb_fbo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index a966028..aad8493
that front buffer rendering and reading works correctly.
Signed-off-by: Nicolai Hähnle nhaeh...@gmail.com
---
src/mesa/state_tracker/st_framebuffer.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_framebuffer.c
b/src/mesa
Certain tests (e.g. piglit's crossbar) crash because they do (possibly
somewhat weird things) with glReadBuffer().
What happens is this:
- Context gets set up, made current
- Stuff gets rendered
- glReadBuffer() is called to change the read buffer
- glReadPixels() crashes because now
of state data caused a crash due to double-free on destruction
of context, because a variable wasn't correctly null'ed out.
Signed-off-by: Nicolai Hähnle nhaeh...@gmail.com
---
src/mesa/drivers/dri/r300/r300_ioctl.c | 16 +++---
src/mesa/drivers/dri/r300/r300_state.c | 18
Hi,
Am Donnerstag 12 Februar 2009 06:29:27 schrieb Dave Airlie:
So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
work.
Yay!
[snip]
So far I've been working on getting the legacy buffer/command code
Am Donnerstag 12 Februar 2009 15:10:11 schrieb Roland Scheidegger:
Compressed textures also seem to be broken, since they'll raise a FPE:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1480239424 (LWP 11180)]
0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48,
Hi,
testing the r300-bufmgr has revealed that the driDestroyDrawable is never
called in very simple applications such as glxinfo or glxgears. This
obviously causes a number of memory leaks. Unfortunately, I don't really
understand that part of the code yet, but I have confirmed that the
Am Montag 11 August 2008 02:53:44 schrieb Stephane Marchesin:
On 8/2/08, Jerome Glisse [EMAIL PROTECTED] wrote:
I might be totaly wrong so feel free to ignore these. I got the feeling
that the user test base on linux kernel is far bigger than ours. Also
i think that our test user base are
Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen:
I'm having troubles obtaining GLX visual with accumulation buffers. It
happens only on Fedora 9. Attached is glxinfo log.
Problem never appears with fglrx drivers, but as you know it's not
available for FC9.
I'm really looking
Am Mittwoch 06 August 2008 02:53:23 schrieb [EMAIL PROTECTED]:
I've been working on a port of DRM for Syllable.? Syllable doesn't support
drivers (or kernel modules) that are on the same level of abstraction
communicate with each other.? For example our sound card drivers can't
communicate
Am Freitag 25 Juli 2008 12:12:59 schrieb Jerome Glisse:
This looks like usual engine lockup followed by CP lockup so
that DMA buffer age never get written and we run out of DMA
buffer thus freelist failing in infinite loop.
I think we now know all the reason why we lockup, while a
fix could
Am Sonntag 08 Juni 2008 03:57:48 schrieb Dave Airlie:
Hmm, the radeon_cp_idle() should purge the destination cache (and wait
for it too, including checking the DC_BUSY bit).
At least the r200 driver has a comment in r200SpanRenderStart (including
a dodgy workaround) which sure looks like
Hi,
I'm currently trying to figure out why glean/texCube reproducably fails on my
R420. That test basically has a number of sections that look like this
loop(..) {
render();
loop(..) {
glReadPixels(..);
check_values();
}
}
The outer loop continuously overwrites the
15 matches
Mail list logo
