Nexus One/Android "CPU có thể được cố định" lỗi

Question

Tôi đang viết một trò chơi đồ họa cường độ cao cho Nexus One, sử dụng NDK (bản sửa đổi 4) và OpenGL ES 2.0. Chúng tôi đang thực sự đẩy phần cứng ở đây, và cho hầu hết các phần nó hoạt động tốt, ngoại trừ mỗi một lần trong một thời gian tôi nhận được một vụ tai nạn nghiêm trọng với thông điệp log này:

W/SharedBufferStack (398): waitForCondition (LockCondition) đã hết thời gian (danh tính = 9, trạng thái = 0). CPU có thể được chốt. thử lại.

Toàn bộ hệ thống sẽ khóa, lặp lại thông báo này và sẽ khởi động lại sau vài phút hoặc khởi động lại theo cách thủ công. Chúng tôi đang sử dụng Android OS 2.1, cập nhật 1.

Tôi biết một vài người khác đã từng gặp lỗi này, đôi khi liên quan đến âm thanh. Trong trường hợp của tôi, nó gây ra bởi SharedBufferStack, vì vậy tôi đoán đó là một vấn đề OpenGL. Có ai gặp phải điều này, và tốt hơn chưa sửa nó? Hay bất cứ ai biết điều gì đang xảy ra với SharedBufferStack để giúp tôi thu hẹp mọi thứ?

Answer 1

Tôi không tin rằng lỗi như vậy có thể xảy ra trong mã âm thanh, SharedBufferStack chỉ được sử dụng trong thư viện Bề mặt. Có lẽ đây là một lỗi trong chương trình swapBuffers EGL hoặc SurfaceFlinger, và bạn nên gửi nó đến bug tracker.

Answer 2

waitForCondition() làm cho việc khóa máy (đóng băng hệ thống).
Nhưng nó không phải là nguyên nhân gốc rễ. Điều này dường như là một vấn đề với

Các nghe khuôn khổ (ur trò chơi có âm thanh?)
-hoặc-
Các GL render-hệ thống phụ.

Bất kỳ thông báo "CPU được cố định" nào trong nhật ký? Bạn có thể muốn xem xét điều này:
http://soledadpenades.com/2009/08/25/is-the-cpu-pegged-and-friends/

Answer 3

tôi đã CPU may be pegged tin nhắn trong LogCat bởi vì tôi đã có một ArrayBlockingQueue trong mã của tôi. Nếu bạn có bất kỳ hàng đợi chặn nào (như trường hợp có bộ đệm âm thanh), hãy đảm bảo chỉ BlockingQueue.put() nếu bạn có đủ điều khiển thời gian để đúng cách BlockingQueue.take() các yếu tố để tạo chỗ cho nó. Hoặc nếu không, hãy xem sử dụng BlockingQueue.offer().

Answer 4

Có vẻ là một vấn đề lái xe với eglSwapBuffers():

http://code.google.com/p/android/issues/detail?id=20833&q=cpu%20may%20be%20pegged&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars

Một workaround là để gọi glFinish() trước cuộc gọi của bạn để eglSwapBuffers(), tuy nhiên điều này sẽ tạo ra một hiệu suất hit.

Answer 5

FWIW, tôi trúng vấn đề này thời gian gần đây trong khi phát triển trên Android 2.3.4 sử dụng GL ES 2 trên Samsung Galaxy S.

Vấn đề đối với tôi là một lỗi trong glDrawArrays tôi gọi - Tôi đã render qua cuối cùng của bộ đệm, tức là "đếm" tôi đã vượt qua lớn hơn số lượng thực tế. Thật thú vị, cuộc gọi đó đã không ném một ngoại lệ, nhưng nó sẽ không liên tục dẫn đến vấn đề bạn mô tả. Ngoài ra, bộ đệm tôi đã kết thúc dựng hình trông sai vì vậy tôi biết một cái gì đó đã tắt.Các "CPU có thể được pegged" điều chỉ làm cho nó khó chịu hơn để theo dõi các vấn đề thực sự.